Carl Lerche, creator of Tokio, discusses the evolution of async Rust over the past decade. The conversation covers Tokio's architectural decisions including work-stealing schedulers and cooperative scheduling, common pitfalls like blocking the runtime with CPU-heavy work, and debugging techniques using tracing and runtime metrics. Key topics include cancellation through Drop, why Tokio became the dominant runtime, io_uring's limited networking benefits, and the future of Rust in high-level web frameworks through projects like Toasty.
Table of contents
Q1. What is TokioConf and why did you decide to organize it?Q2. When people hear “Async Rust,” what should they picture?Q3. How did Tokio begin? Why did Rust need it?Q4. Could Rust have something like Java’s virtual threads?Q5. How does cancellation work in Async Rust?Q6. Why did Tokio become the dominant async runtime?Q7. What about io_uring? Is it the future?Q8. What were the most important design decisions in Tokio?Q9. What are common mistakes in Async Rust?Q10. What’s the best way to debug Async Rust?Q11. What is Toasty, and why are you building it?Q12. Can Rust move into high-level web frameworks?Closing ThoughtsSort: