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
•7m read time• From blog.jetbrains.com
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: