The State of Async Rust: Runtimes
Really, the problem isn't tokio. The problem is this:<p>> An inconvenient truth about async Rust is that libraries still need to be written against individual runtimes.<p>That's really the heart of it. If it was <i>really</i> just a runtime, it wouldn't matter what implementation you plugged in.<p>...but it's not true for the rust runtime; I mean, it'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's hard and lot of work went into this, but let's face this. This article is right:<p>Practically speaking, tokio has become 'the' rust async runtime; but it's an <i>opinionated</i> runtime, that has a life cycle and direction <i>outside of the core rust team</i>.<p>That wasn't where we intended to end up, and it'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 <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.