... no. coroutines are not supposed to be used in, like, more than an extremely small fraction of your codebase if you want to keep your code understandable
Eh, I think coroutines are a convenient way to achieve concurrency and parallelism. If you limit mutation and try to reduce the long reaching accessibility of variables then I think they’re generally very understandable, especially compared to other concurrency/parallelism paradigms.
> Eh, I think coroutines are a convenient way to achieve concurrency and parallelism.
but how often do you need concurrency and parallelism outside of handling network requests and performing some complicated math algorithm (which may be in a lib that you don't touch anyways, e.g. FFT>) ?
e.g. most UI code has to run on the main thread due to macOS / Windows limitations, and in most UI software it is extremely rare to have the kind of chains of callbacks whose readability gets improved by coroutines.
Coroutines are not really for parallelism. I doubt you'll see them much around math heavy code. Possibly if someone implements some Cilk style work stealing executor...
Ideally, but they taint everything they touch, that is why in C# I always start them from some point with Task.Run(), or leave it for the event and request handlers.
... no. coroutines are not supposed to be used in, like, more than an extremely small fraction of your codebase if you want to keep your code understandable