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

11–20 of 46 posts

Re: Asynchronous Programming in Rust book

#11

Post by Tarean »

This approach to async programming feels like a much more leaky abstraction than the 'it's basically semaphores' stuff for m:n threads. Though being able to do so much as a library is nice.

How does async translate calls to other async functions? Is refactoring into smaller async functions less efficient? If not, how does it deal with (possibly indirect) recursive function calls? Does it give up or select a loop breaker?

And what is the purpose of the pingpong between executor->Waker->push onto executor?

I am also still unsure what the approach to multithreading might be. Multiple executors with work stealing or one dispatch executor with worker threads or something else still?

Re: Asynchronous Programming in Rust book

#12

Post by thramp »

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

> What is going on with futures 0.3? Why is everyone still using 0.1?

Futures 0.3 uses nightly only-features that are landing in Rust within (hopefully) the next two releases of Rust. Namely, Futures 0.3 is a way to experiment with async programming using the async/await syntax.

> Why is everyone still using 0.1?

Futures 0.3 is still in flux—but settling down in recent weeks—and is relying on nightly-only features. Futures 0.1 is used heavily in Hyper and Tokio, but we intend to move to Futures 0.3/std::future::Future when they're available on stable or shortly thereafter.

(The Tokio and Hyper projects take backwards compatibility _extremely_ seriously.) (Disclaimer: I help maintain Tokio/Hyper, but am nowhere near are prolific as the main authors.)

Re: Asynchronous Programming in Rust book

#13

Post by leshow »

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

> What is going on with futures 0.3? Why is everyone still using 0.1?

AFAIK becaue tokio isn't upgrading until some issues are ironed out. As long as tokio is on 0.1 the rest of the community will be on 0.1 too.

Re: Asynchronous Programming in Rust book

#14

Post by steveklabnik »

est31 wrote: post #5

There isn't too much activity on this book [1] but I definitely think that more documentation about async programming in Rust is needed. Just recently I wanted to do something in async Rust and it's just such a PITA. I'm writing Rust since 3-4 years now and async throws me back to those first days where I didn't know how to cope with the error messages. Hopefully async/await syntax will improve this experience, but e…

There's just been too much change too quickly. When it settles down, it'll get documented.

Re: Asynchronous Programming in Rust book

#15

Post by steveklabnik »

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?

Sorta, kinda. One big example of when you wouldn't use Tokio is when you don't have an operating system.

Tokio is a good, default choice, but some projects may have different needs.

Re: Asynchronous Programming in Rust book

#16

Post by leshow »

Tarean wrote: post #11

This approach to async programming feels like a much more leaky abstraction than the 'it's basically semaphores' stuff for m:n threads. Though being able to do so much as a library is nice. How does async translate calls to other async functions? Is refactoring into smaller async functions less efficient? If not, how does it deal with (possibly indirect) recursive function calls? Does it give up or select a loop brea…

> How does async translate calls to other async functions? Is refactoring into smaller async functions less efficient?

I believe it builds the calls up into one larger future, so it shouldn't be any less efficient.

I can't answer any of the other questions with any certainty.

Re: Asynchronous Programming in Rust book

#17

Post by steveklabnik »

Tarean wrote: post #11

This approach to async programming feels like a much more leaky abstraction than the 'it's basically semaphores' stuff for m:n threads. Though being able to do so much as a library is nice. How does async translate calls to other async functions? Is refactoring into smaller async functions less efficient? If not, how does it deal with (possibly indirect) recursive function calls? Does it give up or select a loop brea…

> How does async translate calls to other async functions?

There's nothing special going on. Remember, async on a function is something like

  async fn function(argument: &str) -> usize {
to

  fn function(argument: &str) -> impl Future {
so, when you call an async function, you get a Future back. That's true even if it's inside of another async function.

> If not, how does it deal with (possibly indirect) recursive function calls?

Recursive calls to async functions will fail to compile: https://github.com/rust-lang/rust/issues/53690

That said, see that discussion; the trait object form will probably eventually work.

Heavy recursion isn't generally Rust's style, since we don't have guaranteed TCO, so you threaten to overflow the stack and panic.

> Is refactoring into smaller async functions less efficient?

That's a complicated question. It really depends. I don't think it should be, thanks to inlining, but am not 100% sure.

> And what is the purpose of the pingpong between executor->Waker->push onto executor?

Right now, the best resource is https://boats.gitlab.io/blog/post/wakers-i/ and https://boats.gitlab.io/blog/post/wakers-ii/

> I am also still unsure what the approach to multithreading might be.

You have options! Tokio now does multiple executors with work-stealing by default, in my understanding.

Re: Asynchronous Programming in Rust book

#18

Post by etxm »

est31 wrote: post #5

There isn't too much activity on this book [1] but I definitely think that more documentation about async programming in Rust is needed. Just recently I wanted to do something in async Rust and it's just such a PITA. I'm writing Rust since 3-4 years now and async throws me back to those first days where I didn't know how to cope with the error messages. Hopefully async/await syntax will improve this experience, but e…

The documentation is asynchronous.

I’ll show myself out.

Re: Asynchronous Programming in Rust book

#19

Post by agumonkey »

etxm wrote: post #18
est31 wrote: post #5

There isn't too much activity on this book [1] but I definitely think that more documentation about async programming in Rust is needed. Just recently I wanted to do something in async Rust and it's just such a PITA. I'm writing Rust since 3-4 years now and async throws me back to those first days where I didn't know how to cope with the error messages. Hopefully async/await syntax will improve this experience, but e…

The documentation is asynchronous. I’ll show myself out.

await oriented pedagogy

Re: Asynchronous Programming in Rust book

#20

Post by arve0 »

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.

Post reply on HN