8 ms·

Who Runs Your Rust Future? Hands-On Intro to Async Rust

113 points by febin 3mo ago

deleted 3mo ago
[deleted]
jameshungry 3mo ago
[flagged]
Twey 3mo ago
> What is harder to find is the bridge between them, the part that connects understanding how async works to actually shipping with it. There is actually already a tutorial at this level: Tokio has its ‘async in depth’ tutorial [1] that walks you through building a toy runtime and using it to run a future. Not a complaint — you can never have too many tutorials, unless they're about monads — but just a pointer in case you hadn't seen it :) [1]: https://tokio.rs/tokio/tutorial/async https://tokio.rs/tokio/tutorial/async
- explodes 3mo ago
  Ah what a great little tutorial. Thanks for sharing that one. It looks like rust async creates state machines similar to how Kotlin does it with so-called Continuations.
  - Twey 3mo ago
    Yes I really think it should be better advertised! The continuation model is the standard model of async programming and still perhaps the nicest semantically. Rust's big innovation is that futures are polled from the top, i.e. (potentially) advanced in an idempotent way whenever any of their relevant resources progresses, which is nicer for resource-conscious programming because it doesn't require that you capture the stack. It adds complexity over the continuation model from the programmer's point of view, but opens up async programming to a wider range of contexts in a way that is genuinely novel.
vanillameow 3mo ago
I really enjoy the prose of this article. The writing breaks down concepts in a very easily understandable way. Thank you for posting, will definitely finish this one later!
Quarrel 3mo ago
I liked this article because it helped me understand the javacript engine flow better than I had. The rust flow is so much more natural to me.
uxns 3mo ago
With so much AI-produced junk out there, sites like this one are a breath of fresh air. Simple, aesthetic with real educational value. A second place this week (after https://www.makingsoftware.com/ https://www.makingsoftware.com/) where I've happily parked a few hours of my life.
amelius 3mo ago
Don't use async but use threads instead. Threading treats the CPU as a resource, which it is! Whereas async simply locks the CPU, which can deplete the system for longer computations. If you hate garbage collection pauses (which most Rust users do) then don't use async.
- sieabahlpark 3mo ago
  [dead]
- toprerules 3mo ago
  Your confusing concurrency with parallelism. Async allows one core to switch between many threads of execution that can do work and not stop one thread of execution because it needs to wait for a resource. It's beneficial to use async if you're application is I/O heavy even if it's single threaded. > Whereas async simply locks the CPUWhereas async simply locks the CPU This is also completely nonsense, context switching behavior is OS dependent and your average general purpose kernel is not cooperative. You will run for your allotted quanta or reschedule when you run out of coroutines that can execute without waiting for resources.
  - amelius 3mo ago
    > context switching behavior is OS dependent and your average general purpose kernel is not cooperative. True, but if all you are using is async, then you're basically back at Windows 3.1 cooperative multitasking, except now within a Rust program.
    - seabrookmx 3mo ago
      Tokio uses a thread pool with work stealing so it is definitely more advanced than Windows 3.1's model! As other commenters have pointed out, cooperative multitasking is actually a great fit for I/O bound code.
- himata4113 3mo ago
  You use async to preserve system resources. For example you can easily exhaust the host with ~20k connections running a thread-per-connection schema where each thread simply waits for epoll event, async prevents this by having a threadpool of ~16 threads that handle all the connections instead of polling the scheduler wakes it up, asks "do you haev work to do" if not continues to next task. (This heavily varied by the async runtime implementation, each async runtime can and will act differently to maximize efficiency over throughput)
Havoc 3mo ago
Bit weird to have a rust tutorial list JavaScript async as assumed knowledge tbh.
- fyrn_ 3mo ago
  Yeah, it also makes it seem like Rust is weird for using Future as the type name, but actually JavaScript (Promise) is the odd one out here. Probably a JS dev learning Rust without much exposure to other languages
  - steveklabnik 3mo ago
    I think it's also good that we did not name it Promise because there are a lot of differences in implementation that really matter, and so if Rust had gone with the same name, some people might be confused about some things.
  - febin 3mo ago
    Fixed this, thank you.
- the__alchemist 3mo ago
  Could it be that this is related to the high (anecdotally observed) correlation between Async and webdev in rust? Most of the web-related crates I've run into require Async.
- contextfree 3mo ago
  JS async is similar to C# async (which I think it was based on), think lots of developers are familiar with one or both of those. As one of those developers Rust async definitely threw me for a loop (literally?) when I first encountered it.
- cmpb 3mo ago
  I had the same thought, but then I realized that everyone on my team actually _does_ have experience with JavaScript async, so I just rolled with it. Not sure what that's about
preethamrangu 3mo ago
[flagged]
RealityVoid 3mo ago
Ok, what is going on in the comments here? I get people liking the article but this many comments just to say they liked it is very un-HN to me. Smells like bots to me.
- russdill 3mo ago
  Taking a quick look at the commenter's in question, it seems possible that the person who wrote the article asked people they know to boost it on yc. They don't appear to be bots at least.
  - febin 3mo ago
    Author of the article here. No, I haven't asked anyone to upvote or comment. It was posted 2-3 days ago, there were no upvotes. And I was feeling concerned. (I am doing this full time and getting on top of HN for my own work was a dream). I had written articles on bevy and also posted on HN (in last 6 months). But they hardly got any traction on HN. Not sure what happened today, I saw traffic from HN and was surprised to see this on #8. I also noticed few comments looked LLM generated (they got deleted), but I am not sure why someone would do it, I mean the incentive.
likeabbas 3mo ago
Async ruined rust and I’ll stand by that until I die
- wseqyrku 3mo ago
  On the contrary, my life depends on it right now
- bschwindHN 3mo ago
  Async Rust can be nice, especially when juggling multiple tasks and composing them with timeouts and such. Async in an embedded context is actually really nice, too. You can have high level "send this thing over SPI, receive this data from USB" futures and they will run (ideally via DMA) and your CPU can go to sleep, only waking up when interrupts fire from the hardware peripherals you were using.
- WhyNotHugo 3mo ago
  I think it was rushed, and it has some rough edges that are now too late to fix post-stabilisation. But it's neat to have such a runtime. One annoying thing is that it's optimised for multi-threaded runtimes, so the APIs enforce lifetime requirements which don't make sense for single-threaded async applications.
antiobli 3mo ago
Great tutorial, appreciate the approachable language. A lot of writers bathe their articles deep in Rust lingo that only Rust devs can really comprehend.

113 points by febin 3mo ago

deleted 3mo ago

[deleted]

jameshungry 3mo ago

[flagged]

Twey 3mo ago

> What is harder to find is the bridge between them, the part that connects understanding how async works to actually shipping with it. There is actually already a tutorial at this level: Tokio has its ‘async in depth’ tutorial [1] that walks you through building a toy runtime and using it to run a future. Not a complaint — you can never have too many tutorials, unless they're about monads — but just a pointer in case you hadn't seen it :) [1]: https://tokio.rs/tokio/tutorial/async https://tokio.rs/tokio/tutorial/async

explodes 3mo ago
Ah what a great little tutorial. Thanks for sharing that one. It looks like rust async creates state machines similar to how Kotlin does it with so-called Continuations.
- Twey 3mo ago
  Yes I really think it should be better advertised! The continuation model is the standard model of async programming and still perhaps the nicest semantically. Rust's big innovation is that futures are polled from the top, i.e. (potentially) advanced in an idempotent way whenever any of their relevant resources progresses, which is nicer for resource-conscious programming because it doesn't require that you capture the stack. It adds complexity over the continuation model from the programmer's point of view, but opens up async programming to a wider range of contexts in a way that is genuinely novel.

vanillameow 3mo ago

I really enjoy the prose of this article. The writing breaks down concepts in a very easily understandable way. Thank you for posting, will definitely finish this one later!

Quarrel 3mo ago

I liked this article because it helped me understand the javacript engine flow better than I had. The rust flow is so much more natural to me.

uxns 3mo ago

With so much AI-produced junk out there, sites like this one are a breath of fresh air. Simple, aesthetic with real educational value. A second place this week (after https://www.makingsoftware.com/ https://www.makingsoftware.com/) where I've happily parked a few hours of my life.

amelius 3mo ago

Don't use async but use threads instead. Threading treats the CPU as a resource, which it is! Whereas async simply locks the CPU, which can deplete the system for longer computations. If you hate garbage collection pauses (which most Rust users do) then don't use async.

sieabahlpark 3mo ago
[dead]
toprerules 3mo ago
Your confusing concurrency with parallelism. Async allows one core to switch between many threads of execution that can do work and not stop one thread of execution because it needs to wait for a resource. It's beneficial to use async if you're application is I/O heavy even if it's single threaded. > Whereas async simply locks the CPUWhereas async simply locks the CPU This is also completely nonsense, context switching behavior is OS dependent and your average general purpose kernel is not cooperative. You will run for your allotted quanta or reschedule when you run out of coroutines that can execute without waiting for resources.
- amelius 3mo ago
  > context switching behavior is OS dependent and your average general purpose kernel is not cooperative. True, but if all you are using is async, then you're basically back at Windows 3.1 cooperative multitasking, except now within a Rust program.
  - seabrookmx 3mo ago
    Tokio uses a thread pool with work stealing so it is definitely more advanced than Windows 3.1's model! As other commenters have pointed out, cooperative multitasking is actually a great fit for I/O bound code.
himata4113 3mo ago
You use async to preserve system resources. For example you can easily exhaust the host with ~20k connections running a thread-per-connection schema where each thread simply waits for epoll event, async prevents this by having a threadpool of ~16 threads that handle all the connections instead of polling the scheduler wakes it up, asks "do you haev work to do" if not continues to next task. (This heavily varied by the async runtime implementation, each async runtime can and will act differently to maximize efficiency over throughput)

Havoc 3mo ago

Bit weird to have a rust tutorial list JavaScript async as assumed knowledge tbh.

fyrn_ 3mo ago
Yeah, it also makes it seem like Rust is weird for using Future as the type name, but actually JavaScript (Promise) is the odd one out here. Probably a JS dev learning Rust without much exposure to other languages
- steveklabnik 3mo ago
  I think it's also good that we did not name it Promise because there are a lot of differences in implementation that really matter, and so if Rust had gone with the same name, some people might be confused about some things.
- febin 3mo ago
  Fixed this, thank you.
the__alchemist 3mo ago
Could it be that this is related to the high (anecdotally observed) correlation between Async and webdev in rust? Most of the web-related crates I've run into require Async.
contextfree 3mo ago
JS async is similar to C# async (which I think it was based on), think lots of developers are familiar with one or both of those. As one of those developers Rust async definitely threw me for a loop (literally?) when I first encountered it.
cmpb 3mo ago
I had the same thought, but then I realized that everyone on my team actually _does_ have experience with JavaScript async, so I just rolled with it. Not sure what that's about

preethamrangu 3mo ago

[flagged]

RealityVoid 3mo ago

Ok, what is going on in the comments here? I get people liking the article but this many comments just to say they liked it is very un-HN to me. Smells like bots to me.

russdill 3mo ago
Taking a quick look at the commenter's in question, it seems possible that the person who wrote the article asked people they know to boost it on yc. They don't appear to be bots at least.
- febin 3mo ago
  Author of the article here. No, I haven't asked anyone to upvote or comment. It was posted 2-3 days ago, there were no upvotes. And I was feeling concerned. (I am doing this full time and getting on top of HN for my own work was a dream). I had written articles on bevy and also posted on HN (in last 6 months). But they hardly got any traction on HN. Not sure what happened today, I saw traffic from HN and was surprised to see this on #8. I also noticed few comments looked LLM generated (they got deleted), but I am not sure why someone would do it, I mean the incentive.

likeabbas 3mo ago

Async ruined rust and I’ll stand by that until I die

wseqyrku 3mo ago
On the contrary, my life depends on it right now
bschwindHN 3mo ago
Async Rust can be nice, especially when juggling multiple tasks and composing them with timeouts and such. Async in an embedded context is actually really nice, too. You can have high level "send this thing over SPI, receive this data from USB" futures and they will run (ideally via DMA) and your CPU can go to sleep, only waking up when interrupts fire from the hardware peripherals you were using.
WhyNotHugo 3mo ago
I think it was rushed, and it has some rough edges that are now too late to fix post-stabilisation. But it's neat to have such a runtime. One annoying thing is that it's optimised for multi-threaded runtimes, so the APIs enforce lifetime requirements which don't make sense for single-threaded async applications.

antiobli 3mo ago

Great tutorial, appreciate the approachable language. A lot of writers bathe their articles deep in Rust lingo that only Rust devs can really comprehend.