Hello! Me and some other folks who work on the Rust SDK will be around today answering questions in the comments.
Is cdk rust on the works?
General Availability of the AWS SDK for Rust
51–60 of 61 posts
Re: General Availability of the AWS SDK for Rust
#52Hi! Congratulations on GA! Been waiting for this. I just heard about AWS CRT at the AWS ReInvent Innovation talk on Storage. 1. Does the Rust SDK use CRT under the hood? I use the Rust SDK to access S3 and wonder if there are any automatic performance gains? 2. I couldn't find good material on how AWS CRT works and how it is integrated with the Java or Python S3 connectors. I would appreciate a more technical explana…
The Rust SDK does not currently use the CRT under the hood. The CRT is a high performance C-Library for fast HTTP connections (and a lot more).
For S3, there is a meta-layer that interceps requests to S3 and converts them into ranged-gets and multipart uploads for parallelization.
It's quite complex and can also use significantly more memory, but it does allow for *much* faster uploads and downloads in some circumstances.
Re: General Availability of the AWS SDK for Rust
#53Earlier quoted context omitted.
I’d love to know more. Anything you can point to?
A couple of things off the top of my head: The title conflates languages and their implementations. Different implementations prioritize different things. They occasionally do test different implementations, as in the main Ruby distribution vs JRuby, but it is still annoying. The second, and I think largest issue, is that they chose the Language Benchmarks Game as the set of sample programs to test. I do not believe…
> conflates languages and their implementations
A more charitable reading might accept that language names may be used as shorthand for particular language implementations.
In this case:
https://sites.google.com/view/energy-efficiency-languages/se...
~To your knowledge, did such a collection of programs — actually shown to meet that criterion — exist?
~When we emphasize outliers with arithmetic means in "Table 4. Normalized global results for Energy, Time, and Memory".
With medians:
JS 7.25 times slower than C
TS 7.8 times slower than C
~Except `--alwaysStrict` and `--use_strict`
So a JavaScript program may have failed as a TypeScript program, and a different program which worked as TypeScript may have been measured.
~The authors provided a repo, including test program source code, that is still available 5 years later.
page 3, footnote 1 "The measuring framework and the complete set of results are publicly available at https://sites.google.com/view/energy-efficiency-languages"
Re: General Availability of the AWS SDK for Rust
#54Earlier quoted context omitted.
Why would this be specific to the SDK? If the code is Rust without any native libraries being linked, WASM should work out of the box.
Although this is true in theory, in practice you need to be very careful when writing code if you want to target WASM. One example: `SystemTime::now` will panic on some WASM platforms!
True, but library authors shouldn't work around those bugs. It just creates a whole lot of unnecessary legacy code in the wrong places.
Re: General Availability of the AWS SDK for Rust
#55Earlier quoted context omitted.
A couple of things off the top of my head: The title conflates languages and their implementations. Different implementations prioritize different things. They occasionally do test different implementations, as in the main Ruby distribution vs JRuby, but it is still annoying. The second, and I think largest issue, is that they chose the Language Benchmarks Game as the set of sample programs to test. I do not believe…
Thanks for writing all of that out! I appreciate the analysis.
Alternatively
Re: General Availability of the AWS SDK for Rust
#56Earlier quoted context omitted.
A couple of things off the top of my head: The title conflates languages and their implementations. Different implementations prioritize different things. They occasionally do test different implementations, as in the main Ruby distribution vs JRuby, but it is still annoying. The second, and I think largest issue, is that they chose the Language Benchmarks Game as the set of sample programs to test. I do not believe…
> conflates languages and their implementations A more charitable reading might accept that language names may be used as shorthand for particular language implementations. In this case: https://sites.google.com/view/energy-efficiency-languages/se... ~ > representative of the broader set of software written in most languages To your knowledge, did such a collection of programs — actually shown to meet that criterion…
I am not denigrating the benchmark game in this comment, I am saying that the paper does not convincingly make the argument for its thesis. I know you are proud of your work. You yourself encourage people to understand exactly what the benchmark game is and is not. Suggesting that it is representative of all programs is something that you yourself literally have in the FAQ: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> We are profoundly uninterested in claims that these measurements, of a few tiny programs, somehow define the relative performance of programming languages aka "Which programming language is fastest."
Just because I do not think that using the Benchmark Game is a good idea to demonstrate their thesis does not think that I do not think the Benchmark Game is bad.
Additionally,
> The authors provided a repo, including test program source code, that is still available 5 years later.
That link gives "We are sorry, but you do not have access to this service".
Re: General Availability of the AWS SDK for Rust
#57Earlier quoted context omitted.
> conflates languages and their implementations A more charitable reading might accept that language names may be used as shorthand for particular language implementations. In this case: https://sites.google.com/view/energy-efficiency-languages/se... ~ > representative of the broader set of software written in most languages To your knowledge, did such a collection of programs — actually shown to meet that criterion…
I am not denigrating the benchmark game in this comment, I am saying that the paper does not convincingly make the argument for its thesis. I know you are proud of your work. You yourself encourage people to understand exactly what the benchmark game is and is not. Suggesting that it is representative of all programs is something that you yourself literally have in the FAQ: https://benchmarksgame-team.pages.debian.ne…
Trawling through the wayback machine, I did find that the older pages link to https://github.com/greensoftwarelab/Energy-Languages, which does seem to provide the contents of the specific programs used and the benchmarking software. Excellent.
Re: General Availability of the AWS SDK for Rust
#58Earlier quoted context omitted.
> conflates languages and their implementations A more charitable reading might accept that language names may be used as shorthand for particular language implementations. In this case: https://sites.google.com/view/energy-efficiency-languages/se... ~ > representative of the broader set of software written in most languages To your knowledge, did such a collection of programs — actually shown to meet that criterion…
I am not denigrating the benchmark game in this comment, I am saying that the paper does not convincingly make the argument for its thesis. I know you are proud of your work. You yourself encourage people to understand exactly what the benchmark game is and is not. Suggesting that it is representative of all programs is something that you yourself literally have in the FAQ: https://benchmarksgame-team.pages.debian.ne…
> … not denigrating the benchmark game …
Agreed. My response was to your comments about the "Energy Efficiency across Programming Languages" conference paper.
You found the JS/TS "very confusing": I suggested a simple cause.
~
Huh?
How have you read "profoundly uninterested" to mean "Suggesting that it is representative …" ?
~
I really did just click-on (Microsoft Edge) the link odyssey7 provided, click-on the "footnote 1" link in the paperSLE.pdf, click-on the "[1] Measuring Framework & Benchmarks" link, without any difficulties.
Re: General Availability of the AWS SDK for Rust
#59Earlier quoted context omitted.
The blog post mentions support for 300+ services. I have a couple of questions: 1. It would be interesting to see a comparison between the Rust service coverage and other language SDKs that have been around for a while such as Java. Is there such a place to see this comparison? 2. Will the Rust SDK stay up to date with the latest services as they're announced? I'm very excited to see this announcement. It's been a lo…
Disclaimer: I am not working on the SDK nor for Amazon. As far as I read the code of some AWS SDKs, the SDKs (in most languages) are generated from interface files and are thus always in-sync and cover the same APIs in every language.
As a founding, but former, member of the SDK team: can confirm.
Re: General Availability of the AWS SDK for Rust
#60Hello! Me and some other folks who work on the Rust SDK will be around today answering questions in the comments.
Curious about FIPS compliance of the crypto modules, any insight?