5 HN users recommended this talk4 months2020–2026score 4.5
Years with an HN recommendation, 2007–2026
HN points to it to show how deliberately the Rust team arrived at async/await and why it was chosen over alternatives like green threads.
Steve Klabnik walks through the history of Rust and how its design evolved toward async/await, including the alternatives tried and dropped. He also discusses the difficulty of adding a major feature to a language.
“It will show you how meticulous the core team is and how long it took to arrive at this incredible, best in class design.” (HN, 2020)
Oh boy. The author of this post gave a speech about Rust’s journey to async/await: [this video] I highly recommend you skim it. It will show you how meticulous the core team is and how long it took to arrive at this incredible, best in class design.
How carefully the Rust team arrived at async/await.
I was referring to the fact that it is the only async implementation that I know of that compiles to a state machine that doesn't need to allocate new memory for each continuation. I think it will translate to extremely fast web services in practice. Pinning is of course part of the elegant solution. There are some great videos about it: [this video] [link]
I believe these are the talks from Steve that he's referring to. It was enlightening for me: 1. Rust's Journey to Async/Await - [this video] 2. The Talk You've been Await-ing for - [link] The first video goes into all the bits you're concerned about and all the things that Rust has tried before arriving where they are now
Covers what Rust tried before settling on async/await.
As you probably know, Rust ended up with async/await. This video goes deep into that and the alternatives, and it changed my opinions a bit: [this video] Golang differs from Rust by having a runtime underneath. If you're already paying for that, it's probably better to do greenthreading than async/await, which is what Go did. I still find the Go syntax for this more bothersome and error-prone, as you said, but there are other solutions to that.
Java is different. Tomcat's thread pool is the older way. A lot of newer stuff was using something promises-related instead with an event loop. But then recently Java added virtual threads which should obviate the need for that, similar to Go. Rust considered virtual threads but chose against that because it requires a more abstracted runtime like Java and Go have. Great preso on this [this video] All the "async" stuff is super poorly named. They mean cooperative multitasking, or I guess "async within a single kernel thread." Yeah multiple kernel threads are asynchronous but "async" doesn't mean that :S
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
5 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Read more