> 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 :)
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!
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/) where I've happily parked a few hours of my life.
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.
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.
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.
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
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.
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.
Great tutorial, appreciate the approachable language. A lot of writers bathe their articles deep in Rust lingo that only Rust devs can really comprehend.
18 comments
[ 12.8 ms ] story [ 107 ms ] threadThere 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
It looks like rust async creates state machines similar to how Kotlin does it with so-called Continuations.
The rust flow is so much more natural to me.
If you hate garbage collection pauses (which most Rust users do) then don't use async.
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.