This makes sense, and I know it's why Rust abandoned green threading. But I can't help but worry that the focus on async I/O in Rust as a way of avoiding this issue is going to bring the language down a path that isn't as ergonomically pleasant as Go or Erlang's M:N threading for things like highly concurrent web services. Do you share this concern, or do you think Rust can achieve the same level of ergonomics without the impedance mismatch?
I hope the Rust team takes a look at Kotlins coroutines (and all the stuff they managed to build on top of them).
I think Kotlin is a good example because it is built ontop of a 1:1 runtime and uses very elegant primitives.
I was pretty disappointed Rust didn't ship with async/await and some form of lightweight thread but it's understandable.
async/await still has the fundamental problem of composability that all the other attempts at sugaring around an event loop have (aka the "functions have colors" problem [1]). It sucks for collaboration, which is one of the most important things for modern software development.
I don't like that article, because (1) it claims Go is doing something new, while Go is really just threads with a particularly idiosyncratic implementation; (2) it ignores the fact that you can convert async to sync by just blocking and sync to async by proxying out to a thread pool. The "what color is your function" problem really isn't a big deal.
