Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

General Availability of the AWS SDK for Rust

aws.amazon.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: General Availability of the AWS SDK for Rust

#41

Post by Matthias247 »

Joeboy wrote: post #38

I realize this is a "how long is a piece of string" question, but I'm wondering what cost benefits you might realistically see from moving lambdas from Python to a faster language like Rust? You pay (partly) for execution time so I guess you should see some savings, but I'm wondering how that works out in practice. Worth it?

Instrument your python code and gather metrics. Maybe use a profiler. If it is heavily CPU limited and it spends all time in python interpreter calls it might benefit from moving to a more efficient language. It it’s mostly waiting on IO (eg remote services) it might be a negligible difference.

Re: General Availability of the AWS SDK for Rust

#42

Post by steveklabnik »

odyssey7 wrote: post #40
Joeboy wrote: post #38

I realize this is a "how long is a piece of string" question, but I'm wondering what cost benefits you might realistically see from moving lambdas from Python to a faster language like Rust? You pay (partly) for execution time so I guess you should see some savings, but I'm wondering how that works out in practice. Worth it?

This paper is not about lambdas and their typical operations specifically, but it shows that across a variety of tasks, as of 2017, Rust is more environmentally friendly than Python. https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...

I am gonna be honest: I hope this paper never gets cited by anyone, ever. There's a number of very weird issues about it, but I don't think what it actually shows is demonstrative of reality, even if it happens to show Rust in a good light.

Re: General Availability of the AWS SDK for Rust

#43

Post by odyssey7 »

steveklabnik wrote: post #42
odyssey7 wrote: post #40

Earlier quoted context omitted.

This paper is not about lambdas and their typical operations specifically, but it shows that across a variety of tasks, as of 2017, Rust is more environmentally friendly than Python. https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...

I am gonna be honest: I hope this paper never gets cited by anyone, ever. There's a number of very weird issues about it, but I don't think what it actually shows is demonstrative of reality, even if it happens to show Rust in a good light.

I’d love to know more. Anything you can point to?

Re: General Availability of the AWS SDK for Rust

#44

Post by steveklabnik »

odyssey7 wrote: post #43
steveklabnik wrote: post #42

Earlier quoted context omitted.

I am gonna be honest: I hope this paper never gets cited by anyone, ever. There's a number of very weird issues about it, but I don't think what it actually shows is demonstrative of reality, even if it happens to show Rust in a good light.

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 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.

Re: General Availability of the AWS SDK for Rust

#45

Post by odyssey7 »

steveklabnik wrote: post #44
odyssey7 wrote: post #43

Earlier 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…

Thanks for writing all of that out! I appreciate the analysis.

Re: General Availability of the AWS SDK for Rust

#46

Post by studmuffin650 »

rusbus wrote: post #27
digitalsanctum wrote: post #15

Earlier 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…

The Rust SDK is built on top of the smithy-rs code generator. On the service coverage front, you'll find nearly 100% parity—There are some legacy APIs that aren't supported. It also doesn't have many "high level libraries" (e.g. S3 transfer manager) that can find for other languages. 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 e…

As a follow-on question, is there plans to integrate the AWS CRT under the hood or does the existence of Tokio and async/await negate the need for it?

Re: General Availability of the AWS SDK for Rust

#47

Post by andrewaylett »

Aeolun wrote: post #17

Sounds like that must have been an absolute bitch to build. I cannot imagine re-implementing 300 existing API’s for Rust from scratch… On the plus side, I guess the work lends itself well to parallelization.

As with all the other AWS SDKs, the bulk of the code is generated. The JSON service definitions are shared, the effort (one expects) is in being adding support for all the different ways in which the JSON indicates that services behave, and making it look like it could have been hand-written.

Re: General Availability of the AWS SDK for Rust

#48

Post by db-news »

Hi! 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 explanation. Do you have any links that explains this in more depth?

Re: General Availability of the AWS SDK for Rust

#49

Post by ursuscamp »

rusbus wrote: post #28
ethagnawl wrote: post #22

Earlier quoted context omitted.

Thanks. To further clarify, the SDK can be used from within a Tokio runtime or using Tokio's facilities in a synchronous runtime. Can other async runtimes be used? (The linked post seems to imply that they can.) It looks like Tokio gets installed as a dependency and I see the following when trying to use the futures package: > thread 'main' panicked at /home/dev/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aw…

if you use other Async runtimes, you need to "wire them up", in this case by providing a "sleep" implementation. I'd strongly recommend using Tokio, especially if you're a beginner. I think the "beefy" statements are not necessarily accurate. You can use it as a single-threaded runtime if you want. Tokio is not going to have a significant impact on your compile times or binary size (given you're already using the SDK…

I largely agree with this, honestly. Just use tokio

Re: General Availability of the AWS SDK for Rust

#50

Post by jamesfinlayson »

maxwellg wrote: post #20
Aeolun wrote: post #17

Sounds like that must have been an absolute bitch to build. I cannot imagine re-implementing 300 existing API’s for Rust from scratch… On the plus side, I guess the work lends itself well to parallelization.

A good chunk of the AWS SDKs are codegen’d - it’s the only possible way to support the sheer volume of stuff they need.

Agreed - the Java SDK v2 has had 20 updates this month alone (sometimes two or three times in one day) so definitely not much in the way of manual updates.
Post reply on HN