Fwiw, I think C++ as a language has never been at a better place. There's so many great things in the language now like coroutines, concepts, placeholder NTTPs, CNTTPs, designated initializers. The list goes on and on. I think it's hard to argue against the direction that C++ is evolving as a core language. I would say that LEWG's output is less than optimal and this is because LEWG can't thrive without a Boost and Boost can't thrive without LEWG's participation. They need each other and Project Beman is an attempt to return to that form. If it actually brings LEWG members back to a Boost-like place, that's only really a positive for C++. re: coroutines vs fibers Stackless coroutines are a better fit for standardization. The exemplar of the success of stackful coroutines is Go. Many other GC'd languages have fiber implementations as well like Kotlin/Java. The thing to note here is that these languages also have incredibly sophisticated runtimes that enable them to make efficient usage of these constructs. Systems languages have to use system APIs to create fibers which is something hard to retrofit against the C++ abstract machine. Stackless coroutines are a simple front-end transformation so they're easy to fit against C++'s abstract machine which is why they were kind of a slam dunk to standardize. And I think they're actually quite good as well. I've written async networking implementations in both Rust and C++ and personally, I think C++'s are better solely for how they handle resuming an awaiting task. I don't think the function coloring thing is an issue in practice or at least it's never something I've run up against even when I worked full time in Node. I've seen a lot of Rustaceans complain equally about this but I think it's because they're trying to shoehorn a design that just isn't workable with the tools available and they're refusing to compromise. One thing I've seen that surprised me was the contortions a Gopher will go through to guarantee a suspension point. It's interesting that in practice, the implicit suspension of a routine becomes undesirable because at a point in time, a user wants to *guarantee* a suspension and an explicit `co_await` or `.await` gives the developer a sense of psychological security. In short, it's a good thing Asio wasn't standardized as it was because it included async. It should've just been blocking I/O only. The other problem is, its interfaces are heavily coded against *existing* networking system APIs and now that we have io_uring, we see that the evolution of operating systems introduces backwards-incompatible API breaks. It's also a good thing fibers weren't standardized because it's hard to get right in the context of an IS and an abstract machine. If fibers are really such a good idea, then they'll emerge as the successor in the free market of libraries. - Christian