Rust 1.39.0 released

And from the footnote [2] of the above quote — why the potential excited the author so much that he was inspired to write the optimized implementation;

> At the time, I’d been writing some asynchronous object-oriented state machines by hand in C++11. This experience had been so difficult and error-prone that once I read Aaron’s post, it was inception: I couldn’t get the idea out of my head, and more than anything, I wanted to start using Rust at my job. Eventually, this led me to make a fateful decision, and find a new job where I could invest more of my time in Rust. But that’s another story for another day.

C++ coroutines are being standardized. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p...

The closest thing I know of in C++ would be stackless coroutines. I'm not sure how "standard" they are though, and I've never used them, so I don't know how ergonomic they are.

Async functions are super-common in managed languages like C# JS and Python. Rust manages to get similar ergonomics, with an execution model that allows pluggable schedulers and all sorts of interesting performance properties. Naturally everyone is quite excited.

I suspect that you could build something similar on top of stackless coroutines, but writing a multithreaded work-stealing scheduler in C++ doesn't sound fun. There is also a perception that async/await is a pattern that is mostly useful for writing web services, and that C++ is not a language that you want web developers to use. Us web devs write enough security vulnerabilities as it is in memory-managed languages. Can you imagine what would happen if you got a bunch of rushed web devs to write multithreaded C++ and then exposed it to the internet?

The paper is very clear, I read it the same as you ... which is why I said "explaining some of the downsides of fibers".

Coroutines can have zero overhead. In many cases they can be optimized into simple loops, a classic example is a tree iterator. This allows them to be used for fast collection processing, for example.

But async/await can be used for higher-level scheduling, yes.

Async/await forces the programmer to separate normal "run to completion" functions from async functions which can be suspended, which means you can compile async functions differently from normal functions: the former as suspendable state machines, the latter as regular code. If the programmer doesn't do that, i.e. it's kept "under the hood", the obvious implementation options are:
* Compile all functions as suspendable state machines: slow code because you can't leave values on the stack across a function call, you effectively have to allocate stack frames on the heap.
* Compile all functions as normal code: every suspendable computation has to have its own stack, i.e. fibers. See http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p... for some of the problems there.
* Try to make the compiler detect which functions definitely can't (indirectly) suspend, compile those functions as normal code, use state machines for the rest: totally fails due to separate compilation, FFI, the difficulties of interprocedural control-flow analysis with function pointers, etc.

If you have a different solution no-one has thought of, please let the world know.

Also, as zwol noted, syntactic separation of async from run-to-completion code also helps reasoning about program behaviour. For languages like Rust where the compiler effectively forces you to prove safety, this means in general the code you are allowed to write in a function is different depending on the await-points it contains. (This is better than in C++, where the code you are allowed to write is the same, but the wrong code will exploitably crash.)

Unlike Go or Python, Rust does not have a runtime: the compiler only helps with type inference and declarations, but the implementation of futures or schedulers is made by libraries.

async declarations in Rust are just there to ease declarations and for error message ergonomics, since you could explicitly return a Future type for any async function before this support landed on stable Rust.