3 ms·

There are important distinctions between this code and what it proposed by the OP. See the sections https://vorpus.org/blog/notes-on-structured-concurrency-or

There are important distinctions between this code and what it proposed by the OP. See the sections https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/#nurseries-support-dynamic-task-spawning https://vorpus.org/blog/notes-on-structured-concurrency-or-g... and https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/#there-is-an-escape https://vorpus.org/blog/notes-on-structured-concurrency-or-g... These differences elevate this proposal from handling parallel computation (something that is fairly easy to reason about with normal go routines anyways), to something that actually handles concurrency use cases in general.

eqvinox 6y ago
I was simply making an observation on what the control flow looks like on a source code level, nothing more and nothing less. OpenMP is, as you say, designed for computation, hence the directives it provides. The control flow is still majorly different from go routines, and the argument for this source code expression is IMHO the quintessence of the article. There simply is less to reason about if you have these constructs. With a go routine you still need a join somewhere, which makes it "unstructured" like gotos.