Wow, that API looks pretty awkward and unpleasant, with the co_yield, co_return, etc. Golang has spoiled me.
Edit: @gloryjulio I'm sure it works fine, it's just so unergonomic to express compared to Golang. But this is nothing new with C++, it can do anything.. might not be pretty, but it can do it.
We only use co_await/co_return in the production code. It's basically like JavaScript promise and it's very easy to work with.
Calling coroutine in non-coroutine code is also easy, just do blockingWait(co_routineFunc());
We almost never use multithreading code in the business layer now unless coroutine is actually causing performance issue. I haven't seen that happen yet
With Golang you pay the price of having to go through cgo whenever you want to invoke into C. Which is why Go devs are so stubbornly resisting linking to libc even on platforms where direct syscalls are unstable, for one.
The C++ approach is fully compatible with the C ABI, since in the end it's all just callbacks once you strip all the abstraction layers. Which also means that other languages that use this approach (among them C#, Python, and JavaScript) can easily perform async calls across the interop boundary; this is actually used on Windows, with the OS projecting a common set of async APIs to various languages.
With Go, if you want to do async with some code that's not yours, it has to also be written in Go.
I mean goroutines are not exactly coroutines nor are they threads they are somewhere in between.
And its pretty easy to use the same workflow as goroutines in C++ using std::thread and a concurrent queue implementation, tbb has a decent one and moodycamels is also very good.
It's actual async/await that is a touch annoying but it's also fundamental building blocks, there are currently few abstractions ontop of it.
I also believe strongly async/await is an antipattern. There are better models to handle concurrency well imho that don't use function colouring. Golangs goroutines and channels (effectively actors but that's a can of worms) are a great solution and probably what you should be reaching for instead of async/await.
Except goroutines will absolutely spawn a thread which a coroutine by definition wont.
Goroutines are parallel, coroutine are concurrent. Those are not the same thing.
Coroutines co-operatively yeild to other coroutines. Parallel constructs run in parallel at the same time. Goroutines can run in parallel at the same time and thus are not a coroutine.
My understanding is that goroutines don't spawn threads per-se. They can be executed on parallel event loops, but that can be true for stackess coroutines in c++ for example.
Yeah goroutines are a pretty high level abstraction but they are definitely closer in concept to green threads than to coroutines.
You can run a C++ coroutine on a seperate thread but you effectively need to build all the task handling logic yourself of use a library that's build that out. Goroutines you don't need to use a specialised sleep fuction which is actually changing coroutine state, setting a timer and yeilding. You just sleep as an example
Edit: @gloryjulio I'm sure it works fine, it's just so unergonomic to express compared to Golang. But this is nothing new with C++, it can do anything.. might not be pretty, but it can do it.