The Evolution of Async Rust: From Tokio to High-Level Applications

Name: The Evolution of Async Rust: From Tokio to High-Level Applications
Uploaded: 2026-02-13T06:30:28.000Z
Duration: 1 h 10 min 21 s
Channel: JetBrains

JetBrainsFebruary 13, 20261h 10m

Topics34

Introduction to Tokyo and the Rust Ecosystem0:11 Portland Conference Details2:30 Understanding Async Rust4:30 Carl's Background with Rust and Tokyo10:30 Building Mio and the Path to Tokyo14:00 Virtual Threads Question17:00 Cancellation Behavior22:00 Why Tokyo Became the Default27:00 io_uring Strategy and Use Cases28:42 Tokio Uring Crate and Mixing APIs31:02 Ongoing io_uring Development33:02 Key Tokio Design Decisions34:31 Thread-per-Core vs Work Stealing Approaches36:33 Default Runtime Approach39:01 Cooperative Scheduling in Async Rust40:30 Async Event Stabilization and poll/pin42:30 Debugging Async Rust44:00 Hypothetical Debugging Tools46:00 High Tail Latencies48:01 Tokio Console Purpose50:33 Rust's Evolution and Higher-Level Applications51:30 Expansion of Rust into Higher-Level Use Cases55:01 Rust for Long-Lived Applications57:56 Balancing Performance and Ergonomics58:34 Trait System Trade-offs59:31 Toasty Project Goals1:00:01 Target Use Cases1:01:31 High-Level Framework Gap1:02:02 Ruby on Rails Influence1:03:00 Framework Design Philosophy1:05:01 Toasty Escape Hatch Design1:06:00 Query Engine Architecture1:07:30 Framework Development Strategy1:08:01 Performance Benefits1:09:00

In a Nutshell

Carl Lodge explains that Tokio became Rust's default async runtime due to being first and building the ecosystem around it, while most applications should use its work-stealing scheduler rather than thread-per-core approaches for practical performance. The conversation highlights Rust's expansion beyond systems programming into higher-level web applications, with ongoing work on Toasty as an ergonomic ORM/query engine and future frameworks to address the current gap in industrial-grade application frameworks. Key technical insights include io_uring's limited real-world benefits for sockets, the cooperative scheduling nature of async Rust requiring careful yielding, and the importance of defensive cancellation handling.

AI-Generated Notes

These notes were generated by AI and may contain inaccuracies.

Vitaly Bragilevsky from JetBrains Rust team hosts a livestream joined by Carl Lodge from Tokyo. Tokyo is described as the prominent project in the Rust ecosystem. Tokyo is hosting its first conference in Portland at the end of April, with the website tokio.com. The conference marks 10 years since Tokyo was announced in July. Tokyo and Rust have become one of the default ways companies and people build infrastructure-level software for networking services. If building a database or proxy from scratch, Rust is the likely choice due to its maturity and correctness.

Portland was chosen because Carl Lodge lives there, making organization easier with a local partner. The conference is called Tokyo Conf but is really async network programming with Rust. The program committee helped select talks from the community building amazing things.

Async is a general programming construct pattern that has been around for a long time. While many associate async with performance and handling large numbers of concurrent connections, async also provides added flexibility in code structure. Writing timeouts with threads is surprisingly hard, requiring setting timeouts on reads and handling interrupts, which is quite painful. With async code, timeouts can be thrown everywhere easily. Cancellation and managing multiple in-process tasks efficiently is both performance-wise and architecturally a big reason to use async programming.

The early days of async await and the future trait were driven by cancellation and the ability to do timeouts easily, leveraging Rust's properties. With async cancellation in Rust, a future or async block can be dropped, leveraging Rust's drop handler for cleanup, making it nice for managing and canceling work in progress.

Async is both about performance and a way of managing lots of in-flight threads of logic well. It is also about code quality. For managing code with lots of inbound events that can happen anytime, async is a good approach. UI-driven development is all async and event-driven.

Carl started using Rust 12 or 13 years ago, before the 1.0 days. He was working at a company building a performance monitoring tool for Ruby. The Ruby gem agent was taking too much CPU cycle, requiring a switch to native code. While C was the obvious choice, Carl had limited C and C++ experience. Yehuda Katz suggested trying Rust, which Mozilla was building as an experimental safer language for browsers. Yehuda argued it was better to use Rust even though immature than trust C code in production.

Sign in to read the full notes

Get access to AI-generated notes, topic timestamps, and more.

The Evolution of Async Rust: From Tokio to High-Level Applications

Introduction to Tokyo and the Rust Ecosystem00:11

Portland Conference Details02:30

Understanding Async Rust04:30

Sign in to read the full notes