The State of Async Rust: Runtimes
Really, the problem isn&#x27;t tokio. The problem is this:<p>&gt; An inconvenient truth about async Rust is that libraries still need to be written against individual runtimes.<p>That&#x27;s really the heart of it. If it was <i>really</i> just a runtime, it wouldn&#x27;t matter what implementation you plugged in.<p>...but it&#x27;s not true for the rust runtime; I mean, it&#x27;s understandable, how <i>can</i> you have one runtime that is multi-threaded and one runtime that is <i>not</i>, and expect to be able to seamlessly interchange them?<p>I understand it&#x27;s hard and lot of work went into this, but let&#x27;s face this. This article is right:<p>Practically speaking, tokio has become &#x27;the&#x27; rust async runtime; but it&#x27;s an <i>opinionated</i> runtime, that has a life cycle and direction <i>outside of the core rust team</i>.<p>That wasn&#x27;t where we intended to end up, and it&#x27;s not a good place for things to be. I, at least, agree: avoid async. Avoid teaching rust using async. When you need to use it, partition off the async components as best you can. I &lt;3 rust and I use it a lot, but the async story stinks.<p>We should have an official runtime, officially managed, and guided by the same thoughts that guide the rest of the language.<p>What we have now is a circus. After 4 years of async being in stable.