41–50 of 62 posts
When is it actually desirable to imperatively program your cloud provider rather than using something like Terraform? 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.
> 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 Py…
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")'.
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 shoul…
> 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".
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.
Earlier quoted context omitted.
> How often do the domains of systems programming and cloud administration intersect? 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.
Anyone in this space would already have been using apache or nginx, which are in C or C++. How mature are rust's HTTP implementations?
Seems relevant.
Earlier quoted context omitted.
> 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.
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.
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…
Earlier quoted context omitted.
> How often do the domains of systems programming and cloud administration intersect? 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.
Anyone in this space would already have been using apache or nginx, which are in C or C++. How mature are rust's HTTP implementations?
When is it actually desirable to imperatively program your cloud provider rather than using something like Terraform? Obviously there are services meant to be consumed from application code, but the infrastructure provisioning stuff?
> When is it actually desirable to imperatively program your cloud provider rather than using something like Terraform? One place I've done is when your infra needs to dynamically scale up/down based on load.
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.
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.
I worry about that.