I can't help but think that the best minds among language designers and systems programmers have probably already jumped ship to Rust.
> The lifetime of the coroutine state is strictly nested within the lifetime of the caller, and the size of coroutine frame is known at the call site in that case, coroutine state is embedded in the caller's stack frame (if the caller is an ordinary function) or coroutine state (if the caller is a coroutine)
Basically if you limit yourself to only functionality supported in Rust you'll never actually generate an allocation. Once you start using features Rust doesn't support you need to provided memory via some means.
https://en.cppreference.com/w/cpp/language/coroutines#Heap_a...
This is especially pronounced in languages that rely a lot on compiler optimizations. In Haskell you can purposefully use the singly linked list for very large collections, knowing they will be optimized out, until one day the compiler decided not to optimize that and now you have a problem.
There's a reason C++17 made return-value-optimization a proper part of the language with mandatory elision of copies. People like guarantees. Optimizations are but the icing on the cake.