It's a good call out, and one that we're actively engaged with. Matthew has done fantastic work on Rusoto and we'd like to be helpful there. Stay tuned.
From a compiler perspective, Rusoto takes a long time to compile. Some of that is just the sheer volume of code, but also, it wouldn't surprise me if it's hitting bottlenecks in the compiler (e.g. a recently fixed issue in the performance of #[derive(...)] on a huge number of structs). Getting appropriate bits of Rusoto put into the compiler's performance testsuite could help, and profiling the compiler on it would likely turn up some areas for improvement.
I would also love to see support for using Rusoto on non-Tokio runtimes. Given the amount of code generation used for Rusoto, abstracting over the remainder (such as the choice of async traits) based on a feature flag would hopefully be feasible.
And as a secondary thought around Rusoto (which is awesome, but could be even more so) - it would be great if we came up with some way of covering the non-HTTP/REST type services - for example, there are various streaming services (think speech to text, text to speech, etc.) which are simply not covered by Rusoto. So you can configure those services using Rusoto, but not use them. I've written a few medium-hacky clients for things like AWS Transcribe, but it would be great to... well, not have to.
Rusoto is an awesome project though, huge thanks to those who've got it to where it is.
