General Availability of the AWS SDK for Rust(aws.amazon.com) |
General Availability of the AWS SDK for Rust(aws.amazon.com) |
Thanks for all the work on this, looking forward to trying a few new pieces out!
What kind of plans for support of Rust's evolving async ecosystem?
Any particular reason why the public roadmap does not show the columns similar to "Researching", "We're Working On It" like the other similar public AWS Roadmaps? See example for Containers: https://github.com/aws/containers-roadmap/projects/1
Would be nice to have fully working examples on Github, for most common scenarios across most AWS services. This is something that historically AWS SDKs have been inconsistent on. Just a request not really a question :-)
We were hoping async-function-in-trait would land before GA, however, we have a plan to add support in a backwards compatible way when it's released.
> Any particular reason why the public roadmap does not show the columns similar to "Researching", "We're Working On It" like the other similar public AWS Roadmaps?
Our roadmap has unfortunately been in a state of disrepair for some time. We're hoping to get it cleaned up and accurate post GA.
> Would be nice to have fully working examples on Github, for most common scenarios across most AWS services. This is something that historically AWS SDKs have been inconsistent on. Just a request not really a question :-)
There are lots of examples here [1], some simple, some quite complex. If there's something you have in mind, please file an issue! Having great examples is one of our priorities.
[1]: https://github.com/awslabs/aws-sdk-rust/tree/main/examples
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 long time coming.
New services will come out the same day as all other SDKs–All SDKs utilize the same automated system to deploy new releases.
The only exception is services which require extensive custom code. We're still catching up on those for the Rust SDK.
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.
I don't hold my breath
Are there plans to improve the compilation times? Aws sdk crates are some of the slowest dependencies in our build—which feels odd for what are basically wrappers for http clients.
Some of our other design tenets are here: https://smithy-lang.github.io/smithy-rs/design/tenets.html
* https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-w...
* https://andre.arko.net/2019/01/11/parsing-logs-faster-with-r...
(obviously most people will not realize infinity money)
https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...
edit: Tokio can be beefy. You might look at some of the smaller single-threaded runtimes to execute your future in the main application thread if you’re only concerned about serial execution.
> thread 'main' panicked at /home/dev/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aws-smithy-async-1.0.2/src/rt/sleep.rs:128:20: there is no reactor running, must be called from the context of a Tokio 1.x runtime
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 explanation. Do you have any links that explains this in more depth?
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.
One thing I sorely missed was workers for consuming SQS messages. Ended up having an intern adapt a worker for the old community AWS SDK (rusoto) into this: https://github.com/Landeed/sqs_worker
Also on my dream list of features: gRPC support for Lambda.
On the plus side, I guess the work lends itself well to parallelization.
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 that the kinds of programs in the Language Benchmarks Game are representative of the broader set of software written in most languages. They tend towards math-y, puzzle-style programs, and not CLIs, web applications, GUIs, or anything else.
A very specific issue I have is that Typescript and JavaScript are very different in their analysis, and that's very confusing to me, given that all JavaScript is valid TypeScript, and you would execute it in the same way. This may be an artifact of issue #2, which is that the benchmarks game is only as good as the people who wrote the programs, and it's quite possible that the folks who submitted the TypeScript code didn't do as much perf work as the JavaScript code, but it is still a confusing result that's not explained anywhere in the paper.
A final one (and this is the one I remember least well, so I may be wrong here) is that it is not reproducible. They do not mention which date they retrieved the programs from the Benchmarks Game, let alone the source code of the program, nor released the scripts that were used to collect the data, though they describe them. This means that these discrepancies are hard to actually investigate, and makes the results lower quality than if we were able to independently verify the results, let alone update them based on what has changed since 2017, which is an increasingly long time ago.
In short, I do not think this paper is literally useless, though I think that it does not actually demonstrate its central claim very well, and is difficult to evaluate the actual quality of the results, making it a far weaker result than the title would suggest.
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"
> 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".
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.