[Tamschi]

They aren't strictly comparable. While the heap allocation may be optimised out, there is no way to use native C++ coroutines as guaranteed zero-cost construct due to the automatic heap allocation in the API.

Rust's coroutines currently have practical optimisation issues related to instance size (because the compiler isn't smart enough yet in a few places), and the more powerful generator API very much isn't ready yet, but they give you considerably more control over the memory management. It's easy to stack- or pool-allocate coroutines there if necessary for performance, while in C++ you wouldn't be able to use the native language feature where frequent or unmonitored heap allocations from fine-grained coroutine use would be a problem. (Apparently this makes them unsuitable for AAA game development, for example.)

Library-provided coroutines may be more versatile.

[andreidd]

Not entirely true. You can pool allocate a C++ coro.

[Tamschi]

Ah, you're right, I missed it because it's callee-controlled in C++. (See Heap Allocation and Promise on https://en.cppreference.com/w/cpp/language/coroutines , for those curious.)

Rust coroutines evaluate to opaque value types instead of handles, for comparison, so the caller gets to decide what to do with them. Currently they're a bit unwieldy though, until naming (aliasing) their types becomes possible. The unstable documentation for that is here: https://rust-lang.github.io/impl-trait-initiative/explainer/...

(Edit: Sorry, I'd grabbed the wrong second link. Fixed.)