Comparison of Rust async and Linux thread context switch time and memory use
&gt; People often see that there&#x27;s some theoretical benefit of async and then they accept far less ergonomic coding styles and the additional bug classes that only happen on async due to accidental blocking etc... despite the fact that when you consider a real-world deployed application, those &quot;benefits&quot; become indistinguishable from noise. However, due to the additional bug classes and worse ergonomics, there is now less energy for actually optimizing the business logic, which is where all of the cycles and resource use are anyway, so in-practice async implementations tend to be buggier and slower.<p>I disagree with this. I feel like using Async programming is actually much more powerfull and expressive than theaded programming, especially with Rust combinators on streams of futures (for examples: futures_unordered), which allow to trivially express complex concurrency patterns (such as: wait for the first two requests to return something and discard the third request&#x27;s response, and btw also cancel that request). Async programming also allows for structured programming, where each task is an owned resource of a parent tasks, which means that lifetimes of tasks can be controlled and runaway threads can&#x27;t exist (if one is avoiding tokio::spawn). I&#x27;ve been developping [Garage](<a href="https:&#x2F;&#x2F;git.deuxfleurs.fr&#x2F;Deuxfleurs&#x2F;garage" rel="nofollow">https:&#x2F;&#x2F;git.deuxfleurs.fr&#x2F;Deuxfleurs&#x2F;garage</a>) for some time now (a simple distributed object store that implements a subset of S3, not ready for production!), and I&#x27;ve been in awe about how easy it was to write these complex patterns using async Rust.