I did learn from NodeJS and it was good at the time as it helped to push people for something better. However I also learnt from Boost.Asio, Boost.Coroutine, Boost.Context, Boost.Asio, and plenty of members inside and outside Boost's community. Honestly, NodeJS just got stuck in time. It can't hope to grow more than it already did. If you provide a complete copy of NodeJS inside C++ so NodeJS programmers can come over, what is it that you'll offer for them to come here? They already have NodeJS. You need a differentiating factor.
I am convinced by this.
You shouldn't be, because this is not an accurate description of my library.
If I were reviewing the library now, after what I have learned from this thread, my recommendation would have been to reject the library for now, as it was the case when Boost was young, on the grounds that the programming model and the scope is not clear. It is still not clear to me, "when I should use this library". My best approximation is "when I already use Boost.ASIO (directly or indirectly) and I find its (ASIO's) interface too clumsy".
Can you elaborate on what changed your mind exactly? Libraries like this need a scheduler, boost.fiber has one, too. In the case of boost.fiber it's much more elaborate, which I don't consider necessary for async. Hence it just uses a generic scheduler that's already in boost: boost::asio::any_io_executor. A nice side effect of that is that users CAN use asio directly with that on a single thread, but that's not a necessity. They can also plugin their own awaitables, that have nothing to do with asio. I got two examples of that 1. co-awaiting a boost.signal2 https://github.com/klemens-morgenstern/async/blob/master/example/signals.cpp 2. co-awaiting an spsc-queue https://github.com/klemens-morgenstern/async/blob/master/example/spsc.cpp The latter does use two functions from the asio namespace, that should probably be pulled into the async namespace. Note that both functions are related to boost::asio::any_io_executor. Now, let's say you got five threads producing values and pushing them out into an spsc-queue. So you got five event sources that now need to feed a state machine. You can model that with async and since the co-await will already make sure that all is running on a single thread, it'll be much easier to write & maintain. I hope that makes sense.