Why asynchronous Rust doesn't work
&quot;Maybe we could just have kept Rust as it was circa 2016, and let the crazy non-blocking folks write hand-crafted epoll() loops like they do in C++. I honestly don’t know, and think it’s a difficult problem to solve.&quot;<p>I think this is the most underappreciated part of this article. Since when did everything have to be async? There are other ways to represent concurrency that more accurately reflect what the computer is actually doing.<p>For example, an alternative to async is to represent a workstream as a state machine, where state transitions happen between I&#x2F;O. Then, your state machine can be a struct, and each state transition can be an impl function on that struct that takes one or more completed I&#x2F;O requests as input and emits one or more I&#x2F;O requests as output. This saves you from having to implement everything as a closure, which this article rants about.  Your top-level epoll loop merely services I&#x2F;O requests from state machine instances, and invokes your global application logic to start and stop state machines to carry out business logic tasks.<p>I realize that many complicated workstreams could have many states due to all the I&#x2F;O they might do, but the task of converting a high-level workstream into a state machine could be automated by the tooling.