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!
> We are exploring ways to support multiple Rust async runtimes.
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.
> As good as rusoto is, an official SDK is a huge step forward.
Yes. It might not be "a huge step forward" in tech terms, but it would be definitely very positive for wider adoption, especially from "enterprises" where all is based on "standards".
TBH it will be a huge step forward in tech terms - Rusoto is maintenance mode, and it's missing functionality. I had to jump into it just the other day to add S3 Select support.
Ugh. To anyone contemplating using Amplify I would say:
Rolling your own UI components and straight up using the amazon-cognito-identity-js library and wrapping the bits you need in promises, is far far far less of a headache than using Amplify, unless being tied to Webpack and dealing with disgracefully lazy types is your idea of fun.
That's what we're doing actually. I get the impression that Amplify was designed more for vendor-lock-in than actually solving the problem in the best way
> Just like our newer SDKs, AWS used the Smithy toolchain and service models to build AWS SDK for Rust
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.
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.
> managing to produce ergonomic APIs (semi-)automatically [...] I have most experience with the Python library (boto3)
This almost sounds tongue-in-cheek: the slightest use of boto3 makes it seem obviously auto-generated.
It's fine, it even has advantages (whole classes of bugs removed, or at least fixed once fixed everywhere), I just wouldn't call it ergonomic or idiomatic.
I think there is a trend for a set of tools which auto-generate stuff. It started back with web tools generating websites from WYSIWYG, now it is getting everywhere.
We build services and models using https://www.protoforce.io, which also auto-generates client and server side. Generally, it is impossible to generate good code using templates only, so it has to be transpiled.
I think from amazon's side it was coming sooner or later anyway, with the amount of APIs they have - it is inevitable. I just can't see how many teams you need to have to manage all of the client side code for many languages.
How often do the domains of systems programming and cloud administration intersect?
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.
I see an obvious match with python and boto3 but not this.
In a world where you rent computers by CPU time and RAM usage, enterprises that grow large enough find significant cost savings by implementing high-volume services in more resource-efficient ways.
Users in this space also appreciate Rust's reliability properties. They say things like "It's never my Rust services that set off my pager, and that makes me happy."
Systems programming is just the recommended domain.
Personally I think having a strong type system with an IDE that instantly tells you if the data is the right shape is very valuable when interacting with network interfaces.
In Python you either send the request at runtime and see what the server responds with, or you read the docs, both of which are at least 10x slower than an IDE telling you nearly instantly.
Rust's type system can represent null and polymorphic types quite well, both of which are quite common in JSON-like network interfaces.
Macros work well for code generation that is often used to convert a network api spec into code.
Of course you can do types and macros in Python, but neither are primary features of the language so are not as well supported.
There's a lot or growing number of people who don't use Rust for "systems programming" per se.
People are writing web services or data products that would need to interact with cloud services. Object stores, SQL interaction, lambda/serverless, etc.
I'd think that people using this SDK for cloud administration would be in the minority, but it's just a hunch.
Used by real companies at scale. The primary maintainer of the largest one even works at Amazon, though I don’t know if they use it in a network-facing way there. You can also do what folks do in other languages too, and put nginx out in front, if you prefer.
Having a mostly statically linked executable handle this rather than some bastard child of virtual environments and docker images is a dream come true.
Shoutout to the Tools teams which develops cross, it's really amazing, did a project ago and had some problems to compiling static with rustls (OpenSSL really bugs with me, who knows why) do I tried Cross and felt in love, just works
If you have problems using musl with some libs, give it a go, you gonna love it ;P
Our product is built on AWS and is primarily written in Rust. If you're renting compute you'd better make the most of it, cause that's just money down the drain.
> 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.
I often see Rust used for microservices (where Go is often used), for which access to AWS is very nice to have.
I know quite a few cloud administrators that are systems programmers. They love to work in languages that they can lean on their compiler and not runtime to find a lot of mistakes.
Honestly though, VSCode has been pretty good in this respect. Although I wouldn't use it to write Java or Kotlin, but for C/C++/Zig/D/Rust it's been good.
Some things are better, some worse. Highlights for unused code or imports is imho worse in vscode/metals and refactoring isn't as easy. But running tests for me has always been much faster. Not sure if you can use bloop with intelij but incremental compilation is much better in vscode.
I've had mixed success with VSCode and JVM related stuff. Although the projects I was working on were using some really obscure Maven stuff and god forbid gradle.
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.
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.
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?
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 implementing a Terraform provider, for one. At one point I had the scaffolding up to build providers in Rust (contributing to Tonic and Rusoto along the way) - many of the bugs in TF providers would be resolved by generics and type safety.
I have built several services that do dynamic infrastructure provisioning in response to API calls as part of the core functionality. This isn’t unusual.
The Rust community opened an issue on their tracker [0] - it seems that they are not working on one right now:
> Greetings folks! I work on the team that builds the Cloud Client Libraries. Per the last comment - I can absolutely share that we're not actively working on a Rust SDK right now, and we have no immediate plans to start. We completely understand this would be useful, and we'd love to go build it. However, we're focusing all of our energies on Java, Go, Node.js, Python, C#, Ruby, PHP, and C++ at the moment. If you're looking to build something, I'd be happy to bounce ideas with you!
> We are exploring ways to support multiple Rust async runtimes.
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.