They don't want to add abstractions to the language (e.g. Green threads). So, they are doomed to add abstractions to the libs instead, and one way to do cheap concurrency without the help of the language is to use async I/O.

And by cheap I mean cheaper than OS threads. The reactor pattern still adds a lot of CPU overhead to each I/O operation.

What's interesting is that Rust had green threads at one point. They implemented that by making std::io async-capable under the hood. But they didn't like it: too much abstraction cost, and it was preventing to add more native i/o features easily.

So they ditched it and now they are doing exactly the same thing to I/O, just in user space, and without green threads.

> And by cheap I mean cheaper than OS threads. The reactor pattern still adds a lot of CPU overhead to each I/O operation.

You need to pay for concurrency one way or another, there is always going to be some bookkeeping overhead. Whether you pay the price in your language's runtime (like Go) or in a library doesn't mean you're getting for free. However, it looks like the design of Rust's futures will let it reach very throughput.