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

21–30 of 61 posts

Re: General Availability of the AWS SDK for Rust

#21

Post by ursuscamp »

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.

Re: General Availability of the AWS SDK for Rust

#22

Post by ethagnawl »

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.

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

Re: General Availability of the AWS SDK for Rust

#23

Post by ibotty »

digitalsanctum wrote: post #15
rusbus wrote: post #2

Hello! Me and some other folks who work on the Rust SDK will be around today answering questions in the comments.

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.

Re: General Availability of the AWS SDK for Rust

#24

Post by iofiiiiiiiii »

rusbus wrote: post #2

Hello! Me and some other folks who work on the Rust SDK will be around today answering questions in the comments.

What are the differences in the design principles of the AWS Rust SDK compared to AWS SDKs of other languages? In what ways is it special to work best with the Rust ecosystem?

Re: General Availability of the AWS SDK for Rust

#26

Post by anentropic »

habitue wrote: post #14
rusbus wrote: post #2

Hello! Me and some other folks who work on the Rust SDK will be around today answering questions in the comments.

Are there any plans to do the same for CDK?

Yes, it'd be nice to have a CDK based on Rust with ergonomic libs for downstream langs derived from that via FFI (e.g. Python/PyO3) instead of the JSII abomination they ended up with

I don't hold my breath

Re: General Availability of the AWS SDK for Rust

#27

Post by rusbus »

digitalsanctum wrote: post #15
rusbus wrote: post #2

Hello! Me and some other folks who work on the Rust SDK will be around today answering questions in the comments.

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 exception is services which require extensive custom code. We're still catching up on those for the Rust SDK.

Re: General Availability of the AWS SDK for Rust

#28

Post by rusbus »

ethagnawl wrote: post #22
ursuscamp wrote: post #21

Earlier quoted context omitted.

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.

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

Re: General Availability of the AWS SDK for Rust

#29

Post by rusbus »

necubi wrote: post #16
rusbus wrote: post #2

Hello! Me and some other folks who work on the Rust SDK will be around today answering questions in the comments.

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.

Re: General Availability of the AWS SDK for Rust

#30

Post by rusbus »

iofiiiiiiiii wrote: post #24
rusbus wrote: post #2

Hello! Me and some other folks who work on the Rust SDK will be around today answering questions in the comments.

What are the differences in the design principles of the AWS Rust SDK compared to AWS SDKs of other languages? In what ways is it special to work best with the Rust ecosystem?

Probably the biggest one is "batteries included but replaceable." The Rust ecosystem is still maturing, so we did a lot of work to make reasonable default choices but still allow customers to make different ones.

Some of our other design tenets are here: https://smithy-lang.github.io/smithy-rs/design/tenets.html

Post reply on HN