Meh. When rust was designed it didn't make a distinction between blocking and non-blocking functions (here, I mean having a syscall which may yield to the OS sc

Meh. When rust was designed it didn't make a distinction between blocking and non-blocking functions (here, I mean having a syscall which may yield to the OS scheduler, such as `read`). Together with threads, this let users enjoy the traditional kernel-space concurrency model seamlessly. When async got added, this simplification stood in conflict with the new explicit user-space scheduler (reactor-executor in Rust terms). Today, std is a minefield within an async app — your program may deadlock non-deterministically — without as much as a compiler warning. Every project member needs to worry about intricate details of different types of mutices and which std::fs APIs are kosher, and so on. I would have preferred a plug-in system where you could use the same application code with different scheduling backends - threaded by default, the M:N model or even the M:1 model if you're feeling web scale. This way, code reuse would have been a breeze. What we got was a mess of application code where the compatibility matrix (what code is compatible with what runtime) is not clear, enforced or even well documented. Even the proponents of the current model acknowledge that the current ecosystem is fragmented.