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

31–40 of 61 posts

Re: General Availability of the AWS SDK for Rust

#31

Post by marcinzm »

say_it_as_it_is wrote: post #5

What are some valid reasons why people wouldn't now use these rust libraries and extend them to their preferred language? Maintaining clients is tedious work and prone to abandonment.

Black boxes tend to be problematic to debug and if you're wrapping code in a language you don't know then it's a black box.

Re: General Availability of the AWS SDK for Rust

#33

Post by evntdrvn »

rusbus wrote: post #29
necubi wrote: post #16

Earlier quoted context omitted.

Thanks for your work on this! 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.

It's on our radar—one of the biggest issues is that some of the services like EC2 are absolutely massive. We're investigating ways for customers to only compile the operations they need, etc.

thanks, and also thanks for everyone's work on the SDK! It's very exciting for it to hit GA :)

Re: General Availability of the AWS SDK for Rust

#34

Post by jon_richards »

I've been testing this for a while!

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.

Re: General Availability of the AWS SDK for Rust

#35

Post by nailer »

jon_richards wrote: post #34

I've been testing this for a while! 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.

Hah that reminds me of a decade or so ago - there was an entire unofficial node SDK before the official one came out. The unofficial one still supported a bunch of features outside the main one for a while.

Re: General Availability of the AWS SDK for Rust

#36

Post by jon_richards »

ursuscamp wrote: post #21
ethagnawl wrote: post #19

I'm a Rust beginner, so please excuse any naivete herein: Does this SDK _necessarily_ require an async runtime or is it possible to use it in a traditional sync application using whatever extra facilities (e.g. block_on) which would be required to "normalize" it?

You can use tokio’s block_on to sync-ify. You need to instantiate a runtime, but you don’t need to do run your whole application in it, just the Future. 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.

One thing I love about block_on is that it has a dedicated threadpool with a ton of threads. For async code, you want around as many threads as cores so the thread can run at full speed and have the scheduler handle switching, but for block_on, most of the time is sleeping, so the core can just switch between them all and take care of any that are done sleeping. Just don't use it for CPU intensive tasks.

Re: General Availability of the AWS SDK for Rust

#37

Post by jon_richards »

insanitybit wrote: post #25

Huge. I've told people before that the SDK was basically stable, but the fact that it wasn't 1.0 was still concerning for them.

To be fair, seeing the big "DO NOT USE IN PRODUCTION" every time you view the docs doesn't inspire confidence, lol

Re: General Availability of the AWS SDK for Rust

#38

Post by Joeboy »

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?

Re: General Availability of the AWS SDK for Rust

#39

Post by steveklabnik »

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?

Here's a fun answer to that question: Rubygems saved infinity money. That is, they got resource usage down to the point where they could move to the free tier.

* 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)

Re: General Availability of the AWS SDK for Rust

#40

Post by odyssey7 »

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

Post reply on HN