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

Asynchronous Programming in Rust book

rust-lang.github.io

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Asynchronous Programming in Rust book

#21

Post by asdkhadsj »

arve0 wrote: post #20

How much performance is gained by going async instead of blocking threads on modern hardware? Skimmed through https://vorner.github.io/async-bench.html . If I understand it correctly, one get about twice the performance with async. Is this correct? Seems like a compromise (code complexity vs performance) not worth taking.

Not to over simplify, but when you say code complexity, are you referring to the code you read? Like, the dev UX?

If so, I'd argue that long term once async/await have landed properly, the code largely looks and behaves the same. With that said, I've not even used it yet, because I've got no clue when this is landing enough that I can reasonably use it.. and I'm on Nightly lol.

Re: Asynchronous Programming in Rust book

#22

Post by steveklabnik »

arve0 wrote: post #20

How much performance is gained by going async instead of blocking threads on modern hardware? Skimmed through https://vorner.github.io/async-bench.html . If I understand it correctly, one get about twice the performance with async. Is this correct? Seems like a compromise (code complexity vs performance) not worth taking.

That post is from a year ago, a lot has changed.

And, for web servers, it can be more than 2x. For example, look at techempower's plaintext benchmark: https://www.techempower.com/benchmarks/#section=data-r17&hw=...

Hyper gets 7,013,819. It's async. Iron gets 109,815, and is synchronous. That's 63x. Iron uses hyper under the hood, so that should be a good comparison.

Re: Asynchronous Programming in Rust book

#23

Post by bluejekyll »

arve0 wrote: post #20

How much performance is gained by going async instead of blocking threads on modern hardware? Skimmed through https://vorner.github.io/async-bench.html . If I understand it correctly, one get about twice the performance with async. Is this correct? Seems like a compromise (code complexity vs performance) not worth taking.

async isn't only about performance, but has other advantages, like reduced resource consumption. In addition to that async io also gives you better control over how to cancel io reads and writes on systems where the IO is not interruptible.

But you are correct, if you don't have a specific need, async is generally harder than using threads for concurrency. Ideally the async/await work in Rust is going to make that trade-off less extreme than it is today, which may mean more people will feel comfortable using it as it should reduce boiler plate.

Re: Asynchronous Programming in Rust book

#24

Post by bluejekyll »

kingosticks wrote: post #8

I think I'm correct in saying you don't need tokio for async but it seems all non-toy code uses it. Are there any alternatives to tokio out there for writing real async code or is the idea to build everything on it? As if it was std, but it's not... right?

There are systems that for various reasons can't use Tokio. In my own projects, I know there are people who need things to be generic across any executor implementation, as they can't use Tokio.

Tokio itself is great though, so if you have no strong reason not to use it, I'd recommend it.

Re: Asynchronous Programming in Rust book

#25

Post by Animats »

shadowmint wrote: post #9
portmanteaufu wrote: post #7

Earlier quoted context omitted.

You can track the progress of the remaining issues here: https://areweasyncyet.rs/

I know, but I still struggle to get a handle on the state of it really. What is going on with futures 0.3? Why is everyone still using 0.1? How does that relate to these issues? It superficially appears like the whole async story is still in a concept stage...

It's the open source approach to upgrading. All the cool kids are focused on version N+1, which doesn't work yet. The users still on version N don't get support any more because only losers use version N. You see this pattern frequently in open source. The Python 3 debacle spent five years in that state.

Commercial products tend to avoid this. Sales of version N go way down before version N+1 is generating revenue. Overall revenue drops during the transition. That's not good.

Re: Asynchronous Programming in Rust book

#26

Post by steveklabnik »

Animats wrote: post #25
shadowmint wrote: post #9

Earlier quoted context omitted.

I know, but I still struggle to get a handle on the state of it really. What is going on with futures 0.3? Why is everyone still using 0.1? How does that relate to these issues? It superficially appears like the whole async story is still in a concept stage...

It's the open source approach to upgrading. All the cool kids are focused on version N+1, which doesn't work yet. The users still on version N don't get support any more because only losers use version N. You see this pattern frequently in open source. The Python 3 debacle spent five years in that state. Commercial products tend to avoid this. Sales of version N go way down before version N+1 is generating revenue. O…

Note that this isn't what's happening here; tokio is explicitly supporting "version N" in your terminology. Which is why your parent is asking why people still seem to be using the "old" version.

(Also, there's a compatibility layer, so even the people that want to play with the shiny new N + 1 can do so, even though it's not explicitly directly supported.)

Re: Asynchronous Programming in Rust book

#27

Post by arve0 »

asdkhadsj wrote: post #21
arve0 wrote: post #20

How much performance is gained by going async instead of blocking threads on modern hardware? Skimmed through https://vorner.github.io/async-bench.html . If I understand it correctly, one get about twice the performance with async. Is this correct? Seems like a compromise (code complexity vs performance) not worth taking.

Not to over simplify, but when you say code complexity, are you referring to the code you read? Like, the dev UX? If so, I'd argue that long term once async/await have landed properly, the code largely looks and behaves the same. With that said, I've not even used it yet, because I've got no clue when this is landing enough that I can reasonably use it.. and I'm on Nightly lol.

> are you referring to the code you read?

Yes, the code the developer needs to read, write and understand.

I'm not familiar of how async/await will be in Rust, but I guess some code differences/complexities can be:

1. Make sure, manually(?), that all things are async / non-blocking.

2. Implementing Future.poll / wrapping types in Future? (What is Pin? ref https://rust-lang.github.io/async-book/execution/future.html)

3. Async polution, a function that uses async must be async too?

4. Setup some scheduler that maintain how many concurrent async operations one thread has?

5. More verbose error-messages / stack-traces?

Re: Asynchronous Programming in Rust book

#28

Post by hobofan »

shadowmint wrote: post #9
portmanteaufu wrote: post #7

Earlier quoted context omitted.

You can track the progress of the remaining issues here: https://areweasyncyet.rs/

I know, but I still struggle to get a handle on the state of it really. What is going on with futures 0.3? Why is everyone still using 0.1? How does that relate to these issues? It superficially appears like the whole async story is still in a concept stage...

At least 0.2 has been yanked. I started learning futures when 0.2 was already defacto dead (which wasn't documented anywhere, but luckily people at the local Meetup knew), and I kept wondering why no packages were using it, and a lot of compatibility errors cropped up.

Re: Asynchronous Programming in Rust book

#29

Post by hobofan »

bluejekyll wrote: post #23
arve0 wrote: post #20

How much performance is gained by going async instead of blocking threads on modern hardware? Skimmed through https://vorner.github.io/async-bench.html . If I understand it correctly, one get about twice the performance with async. Is this correct? Seems like a compromise (code complexity vs performance) not worth taking.

async isn't only about performance, but has other advantages, like reduced resource consumption. In addition to that async io also gives you better control over how to cancel io reads and writes on systems where the IO is not interruptible. But you are correct, if you don't have a specific need, async is generally harder than using threads for concurrency. Ideally the async/await work in Rust is going to make that tr…

> but has other advantages, like reduced resource consumption

Could you expand on that? I've never heard that mentioned about async before.

Re: Asynchronous Programming in Rust book

#30

Post by steveklabnik »

hobofan wrote: post #29
bluejekyll wrote: post #23

Earlier quoted context omitted.

async isn't only about performance, but has other advantages, like reduced resource consumption. In addition to that async io also gives you better control over how to cancel io reads and writes on systems where the IO is not interruptible. But you are correct, if you don't have a specific need, async is generally harder than using threads for concurrency. Ideally the async/await work in Rust is going to make that tr…

> but has other advantages, like reduced resource consumption Could you expand on that? I've never heard that mentioned about async before.

You can think of a task as being a thread, but it has one single allocation that’s the exact possible stack size. No more, no less. This uses less memory than spinning up a thread with the default stack size. Yes, you could use the proper APIs and get the correct size too, but you have to figure that size out by hand for each thread. It just implicitly happens with tasks.
Post reply on HN