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.
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."
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.
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.
I worry about that.
I can see Rust being attractive for high-traffic network apps, based on the idea of requests-per-second not being amortized over GC pauses.
If you have problems using musl with some libs, give it a go, you gonna love it ;P
https://github.com/rust-embedded/cross
Edit: my dumbass english failed me, sorry.
I often see Rust used for microservices (where Go is often used), for which access to AWS is very nice to have.
Obviously there are services meant to be consumed from application code, but the infrastructure provisioning stuff?
One place I've done is when your infra needs to dynamically scale up/down based on load.
Using the plugin with CLion feels very well integrated, and I’m not sure what else we’d get out of a seperate IDE other than more distinct branding.
But competitive with other languages like Go or Java.
> 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.
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".
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.
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.
's3 = boto3.client("s3")'.
But the consistency is worth it. If you know how to work with boto you can use the java, JS, go, etc sdks easily.
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.
> 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!
For now, we have https://github.com/Byron/google-apis-rs.
Made me chuckle a bit.
I was thinking that it might be just some newer services, but then I saw DynamoDB which has been around for quite a while.
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.
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.
Also, rusoto is a great name and I hope we get to keep it.
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.
