5 ms·
If they really want to help, the most obvious first step would seem to be to formally adopt and throw some full-time resources at the Rusoto AWS library set for
by ufmace 6y ago
If they really want to help, the most obvious first step would seem to be to formally adopt and throw some full-time resources at the Rusoto AWS library set for Rust. It's pretty usable right now, but would certainly benefit from the level of testing, helper methods, and language-specific additions that the officially supported AWS libs have.
- mjasay 6y agoIt'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.
- JoshTriplett 6y agoI'd love to see this as well. 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.
- kolektiv 6y agoAnd 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.
- ufmace 6y agoThanks, that's great to hear!
- masklinn 6y ago> If they really want to help, the most obvious first step would seem to be to formally adopt and throw some full-time resources at the Rusoto AWS library set for Rust. Is it really? Seems to me like that would easily be seen as self-serving, while putting efforts into the ecosystem as a whole means even people who don't care a whit for AWS benefit.
- ufmace 6y agoYou ought to flip that around actually. Yes it is kind of self-serving. But if they won't do something kind of self-serving like make it much easier to use Rust on their main profit center systems, how committed are they really to making sure the language succeeds? It sounds like a good thing to me for a multi-billion dollar internet giant to have a real self-interest in the language and ecosystem succeeding, and to publicly demonstrate that by maintaining a set of interfaces to their massively profitable ecosystem in that language.
- robocat 6y agoIf Amazon wanted to be really self-serving, they would encourage the use of high-CPU usage languages and discourage the usage of languages that are efficient. Because AWS gets paid for CPU hours, anything that increases CPU hours of their customers should be good for their business, and vice versa.
- Corrado 6y agoI work with AWS quite regularly and this is one of reasons I don't play with Rust more. If we had an "official" Rust AWS SDK I would probably be building things with it.