Just so you're aware, C++ has three keywords here: co_async, co_await, and co_return, so it feels a bit odd to complain about this aspect, specifically.
Also, as I mentioned below, Rust fares even better than C++ on minimizing allocations here.
C++ is used in high performing network services all the time, it shouldn't be a shock that Rust gets used for them as well.
> Just so you're aware, C++ has three keywords here: co_async, co_await, and co_return...
This is admittedly an unimportant correction to what you said that doesn't in any way change your point; and yet, I still think it is an important one to keep in mind for people who only might end up with an indirect understanding of the C++ feature: C++ additionally chose to add a specialized co_yield... and specifically does not have co_async! This latter tradeoff then relates to the Rust discussions I have seen come up again recently due to the article "Was async fn a mistake?".
C++ strongly depends on the actual implementation quality by leaving a lot of things to implementations. For example, the person leading the coroutine implementation in clang is very inconsistent on minimizing allocations than the GCC implementations. As an example they implemented a generator system using C++ coroutines that eventually compile down to a single instruction (https://godbolt.org/z/nsTjjGbn4).
As a counter argument though, clang's support for coroutines is still buggy and not ready for production use.
Rust was not the impetus for C++ getting this feature, just to be clear about it. Or at least, I never read that in any of the many papers over the years working through the design.
Also, as I mentioned below, Rust fares even better than C++ on minimizing allocations here.
C++ is used in high performing network services all the time, it shouldn't be a shock that Rust gets used for them as well.