5 ms·
Coroutines aren't necessary for a graph of tasks. I think it's arguable they even help, since you would want to explicitly synchronize state or not have it at
by BubRoss 7y ago
Coroutines aren't necessary for a graph of tasks. I think it's arguable they even help, since you would want to explicitly synchronize state or not have it at all.
I also think the trend of continually trying to solve all software problems like concurrency and architecture at the language level is a dead end. If you try to solve every problem with your programming language you are bound to end up with enormous compromises in speed, tools etc.
- dnautics 7y agoThe reason why people solve concurrency at the PL level is because it performs better and has better tooling than solving it at the OS level.
- otabdeveloper4 7y ago> it performs better No. Only for interpreted languages that need to deal with extra locking issues. (Python's GIL is the most famous case, but every interpreted language has something analogous.) > has better tooling Well, no. Nothing beats 'htop' or 'perf' or systemd. Coroutines for C++ are mostly a tool for rewriting callback-heavy code to be more concise; i.e., syntactic sugar, not a way to do real parallelism effectively.
- dnautics 7y ago>Well, no. Nothing beats 'htop' or 'perf' or systemd. Have you seen erlang's observer? If you're really good with the tools, you can trap an infinite loop and have introspection into the exact call parameters that are causing problems, stop the resource hog, and write a regression test around it in short time.
- otabdeveloper4 7y agoNo, I haven't. I've seen Python's and Node's async/await implementations, however, and basing my opinion on those.