Some edits a bit too late for HN to allow them: 1. I updated the gists a bit for clarity, hopefully without accidentally moving any goalposts. 2. In addition

Some edits a bit too late for HN to allow them: 1. I updated the gists a bit for clarity, hopefully without accidentally moving any goalposts. 2. In addition to the tradeoffs mentioned in the sentence "If those aren't priorities for you...", I didn't really respond directly to your points about loop-blocking causing event loop hangs. The possibility of loop-blocking causing the entire concurrency system (rather than just, say, one request's routines) to malfunction is a real drawback of async/await systems. Whether or not it's a deal breaker for your using such a system boils down to trust, I think. If your program is running a lot of background routines whose behavior you don't trust to have a low likelihood of loop-blocking, then async/await might be problematic for you. This is analogous to deciding whether to include a piece of functionality as a library linked into your main program, or to include it as a subprocess/IPC interface instead. If you don't trust that functionality not to e.g. corrupt memory, you may choose the latter. I think Tokio specifically is better at mitigating those drawbacks of async/await concurrency models than many other systems, due to its abilities to a) provide fine-grained and accurate detection of loop-blockers, and b) to move task execution between threads to get around potentially stuck routines. Those are just mitigations, not solutions, but they're substantially better than what's offered by e.g. JavaScript.