> 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 :)
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 35 days 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.
Havoc 36 days ago [-]
Bit weird to have a rust tutorial list JavaScript async as assumed knowledge tbh.
the__alchemist 36 days 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 36 days 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.
fyrn_ 36 days 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 36 days 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 36 days ago [-]
Fixed this, thank you.
cmpb 35 days 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
RealityVoid 36 days 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 36 days 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 36 days 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.
uxns 36 days 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/) where I've happily parked a few hours of my life.
antiobli 36 days 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.
likeabbas 36 days ago [-]
Async ruined rust and I’ll stand by that until I die
WhyNotHugo 23 days 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.
bschwindHN 36 days 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.
wseqyrku 36 days ago [-]
On the contrary, my life depends on it right now
vanillameow 36 days 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!
36 days ago [-]
Quarrel 36 days 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.
jameshungry 36 days ago [-]
[flagged]
preethamrangu 36 days ago [-]
[flagged]
amelius 36 days 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.
himata4113 36 days 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)
bigstrat2003 36 days 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...
Sure, if you need to run 20k connections then use async. But the fact of the matter is that the vast majority of software is not going to take on 20k connections. Those people (i.e the majority of software devs) should use threads, because they are much easier to reason about and work with.
himata4113 36 days ago [-]
async gives you a few other advantages, it allows you to handle bi-streams much easier than two sync threads especially when it comes to synchronization.
tancop 36 days ago [-]
[dead]
LtWorf 36 days ago [-]
The problem with all these async things is that people don't understand what's actually happening.
It's just doing a loop and a call to poll(), that's it.
It's way way way less expensive than using threads. Of course you must give control to your main loop every once in a while, so if you have a long computation you either create a thread or split it and return control to your main loop.
It's how all GUI programming has always been done.
Salgat 36 days ago [-]
The whole point of async/await (besides allowing synchronous style code instead of callbacks) is that it lets you yield the thread efficiently back to the executor (OS threads have a massive overhead in comparison). And if you're doing something that blocks the thread instead of yielding it, you can choose between either spawn_blocking or a thread pool.
toprerules 36 days 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 36 days 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 36 days 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.
inigyou 36 days ago [-]
They are two different models and sometimes one is better than the other. Async tends to win for IO-bound code (due to using less memory for each blocked coroutine) and threads for CPU-bound code.
toast0 36 days ago [-]
You can mix and match. For work, I run a conferencing server ... packet processing runs in one thread per core, out of band signalling runs in async on a separate pool of threads. It used to all be async, but using threads for packet processing shaved a little cpu, doing my own timers shaved a little cpu, cpu pinning the threads and the sockets shaved a little cpu, and at the end of the day we shaved a couple instances... too bad instance cost is immaterial compared to bandwidth. Also, it probably drives my coworkers crazy ... but there's really only one spot where it causes issues, so eh, it's fine.
For other things, async task (or green thread, whatevs) per connection is a very nice model that you can't do with thread per connection because I don't think OSes are happy to gave hundreds of thousands of threads.
skydhash 36 days ago [-]
> For other things, async task (or green thread, whatevs) per connection is a very nice model that you can't do with thread per connection
I don’t think I ever seem this patterns, What I’ve seen is either a thread pool for tasks (what essentially async is), or dedicated threads for each parts of the processing (a thread for the UI, and a thread for some background services like playing music).
tcfhgj 36 days ago [-]
> I don’t think I ever seem this patterns, What I’ve seen is either a thread pool for tasks (what essentially async is)
this doesn't really contradict with
> async task (or green thread, whatevs) per connection
The async tasks will probably run on a thread pool (e.g. in tokio).
sieabahlpark 36 days ago [-]
[dead]
Rendered at 20:43:59 GMT+0000 (UTC) with Wasmer Edge.
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
It looks like rust async creates state machines similar to how Kotlin does it with so-called Continuations.
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.
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.
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.
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.
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.
Sure, if you need to run 20k connections then use async. But the fact of the matter is that the vast majority of software is not going to take on 20k connections. Those people (i.e the majority of software devs) should use threads, because they are much easier to reason about and work with.
It's just doing a loop and a call to poll(), that's it.
It's way way way less expensive than using threads. Of course you must give control to your main loop every once in a while, so if you have a long computation you either create a thread or split it and return control to your main loop.
It's how all GUI programming has always been done.
> 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.
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.
As other commenters have pointed out, cooperative multitasking is actually a great fit for I/O bound code.
For other things, async task (or green thread, whatevs) per connection is a very nice model that you can't do with thread per connection because I don't think OSes are happy to gave hundreds of thousands of threads.
I don’t think I ever seem this patterns, What I’ve seen is either a thread pool for tasks (what essentially async is), or dedicated threads for each parts of the processing (a thread for the UI, and a thread for some background services like playing music).
this doesn't really contradict with
> async task (or green thread, whatevs) per connection
The async tasks will probably run on a thread pool (e.g. in tokio).