I was a fan of async code 10 years ago, but now I'm getting more and more a believer that all those coroutine/fiber/etc models "do not spark joy". It's not just

I was a fan of async code 10 years ago, but now I'm getting more and more a believer that all those coroutine/fiber/etc models "do not spark joy". It's not just the C++ version. One thing which usually happens is that engineers get overwhelmed with 2 threading models: They might already have a hard time to understand how normal threading works, and coroutines add another dimension on top of that. That's a non-issue for the engineers working on the proposals and some of the affected libraries since they are domain experts, but the minority of implementors of an API server or users of a HTTP client are actually IO experts. The second thing which usually happens is that a couple of ecosystems start to exist on top of the foundations which are incompatible with another. So you no longer write code in C++, Rust, Python, Java etc. You are writing code in asio, tokio, asyncio or netty. While most of these e.g. have some interoperability or can coexist with other async runtimes running on different threads it's also not something easy. And last but not least every one of the implementations has another set of limitations that one or the other person will be unhappy about. Whether its additional heap allocations, mandatory synchronization, lazy vs immediate execution, cancellation behaviors, etc. All in all coroutines seem good tools to make reaching performance goals in a way that's a bit more pleasant compared to what we had 10 years ago (callbacks), but they always seem to be a compromise. I'm wondering whether at some point we will see an uptake on fixing the shortcomings of plain threads to avoid having to reach out for coroutines and a decline in those. But security challenges and mitigations make it continuously harder to decrease system call overhead.