As good as rusoto is, an official SDK is a huge step forward. Many were wondering how AWS could be "commited to Rust" but not provide an official SDK, this looks great!<p>> We are exploring ways to support multiple Rust async runtimes.<p>Looking to be runtime agnostic from the start is a good sign, although it can be challenging in async rust's current state. It looks like they aren't tied into much async IO, so it should be relatively easy for this library.
> Just like our newer SDKs, AWS used the Smithy toolchain and service models to build AWS SDK for Rust<p>This is pretty impressive. I haven't looked at the SDK in detail, but managing to produce ergonomic APIs (semi-)automatically based on some service models for language as complex as Rust seems like a major accomplishment. I have most experience with the Python library (boto3) which is bit weird at places, but the Pythons dynamic nature is pretty good at hiding lot of that weirdness. Interesting to see how that works out for Rust where so much is static and explicit instead.<p>This also means that the possibility for multiple runtimes might not be that far fetched idea, if they can just make a code generator that spits out different flavors of the SDK.
How often do the domains of systems programming and cloud administration intersect?<p>I'm assuming that rust programs are primarily used in systems programming and that this SDK would be used for cloud administration but I could be wrong.<p>I see an obvious match with python and boto3 but not this.
This is huge for Rust. With Microsoft Windows SDK and now with this, Rust is starting to get first party support on platforms.<p>More so than language syntax, the driver of adoption of a language is ecosystem. Rust is rapidly building up a very impressive ecosystem around it.
Rusoto was an amazing effort. I was pretty sad when it was semi-sunset, but then I realized how all of this was entirely voluntary work.<p>There's been a massive amount of new AWS features recently and this made the inofficial SDKs lag behind. Looking forward to having an officially maintained SDK. Hope the documentation will be better than the generated ones in Rusoto.
Rusoto is awesome, but looked to have an uncertain future. I hope the new SDK can reach the same level of quality and breadth fairly quickly.<p>Also, rusoto is a great name and I hope we get to keep it.
Off hand question for Rust: if memory is borrowed, I gather Rust does not need --- perhaps resists --- C++ style allocators? Here I give emphasis to owner of the (heap) data rather than efficiency. Both languages might use an allocator for fast re-use, less fragmentation, MT support etc.. On the the hand STL strings and containers are replete with allocators in their constructors leading to such questions like if two non-empty std::vector<T> A,B vectors are equal (same size, specialized both on T, resp. elements equal) is A==B true if A has a different allocator from B?<p>Now granted allocator aware containers is a STL thing not per se a C++ thing. But the STL should leverage C++ design to the good ... so it's not too wrong or off base to think about the language in terms of a primary exemplar library.
When is it actually desirable to imperatively program your cloud provider rather than using something like Terraform?<p>Obviously there are services meant to be consumed from application code, but the infrastructure provisioning stuff?
In turn with this release I learned that S3 isn't supported from the beginning because it's the only AWS service using an XML protocol.<p>Made me chuckle a bit.
That's an odd set of initial services.<p>I was thinking that it might be just some newer services, but then I saw DynamoDB which has been around for quite a while.