"may" does the same job as async/await (eg, happily support thousands of network threads on one native thread), runs at about the speed as async/await https://www.techempower.com/benchmarks/#section=data-r21 but the code looks completely "normal" - so special no keywords are needed, and almost none of the usual Rust async/await complaints apply. "Almost" because one does apply: may introduces coloured code, just like async/await. (If it didn't, it would run slower than async/await.)
Also, there is: https://github.com/rust-lang/rust/issues/111272 Translated: co-routines currently use malloc to allocate stacks, so if you overflow the stack you get the experience the C like joys of random memory corruption, with no warning. Why it's implemented like that is a bit of a mystery, given Linux and BSD offer ways to create fast "safe" stacks, and in fact this is the very mechanism used every native thread stack, including Rust's main stack: https://man7.org/linux/man-pages/man2/mmap.2.html (see: MAP_GROWSDOWN). Anyway, as may uses the stacks from co-routines it also suffers from this problem.
Hopefully, this will now be fixed. Generator's are interesting, but somewhat esoteric. Event driven I/O is now main steam, and as Go demonstrates green threads are the least painful way to do it.
"may" does the same job as async/await (eg, happily support thousands of network threads on one native thread), runs at about the speed as async/await https://www.techempower.com/benchmarks/#section=data-r21 but the code looks completely "normal" - so special no keywords are needed, and almost none of the usual Rust async/await complaints apply. "Almost" because one does apply: may introduces coloured code, just like async/await. (If it didn't, it would run slower than async/await.)
Also, there is: https://github.com/rust-lang/rust/issues/111272 Translated: co-routines currently use malloc to allocate stacks, so if you overflow the stack you get the experience the C like joys of random memory corruption, with no warning. Why it's implemented like that is a bit of a mystery, given Linux and BSD offer ways to create fast "safe" stacks, and in fact this is the very mechanism used every native thread stack, including Rust's main stack: https://man7.org/linux/man-pages/man2/mmap.2.html (see: MAP_GROWSDOWN). Anyway, as may uses the stacks from co-routines it also suffers from this problem.
Hopefully, this will now be fixed. Generator's are interesting, but somewhat esoteric. Event driven I/O is now main steam, and as Go demonstrates green threads are the least painful way to do it.