[sriram_malhar]

I think you read a different article, or read stuff into it that the author was not talking about.

This is about contrasting structured vs unstructured concurrency. The language, the threading model, how threads communicate and coordinate ... none of them are germane to the issue.

Wherever you have a fork without a join in the same scope, it is unstructured and gives rise to some concurrency issues.

Structured concurrency promotes composition, similar to ordinary function composition. For ordinary functions, the caller's control flow is logically blocked from proceeding until the callee is done. Similarly, in a structured concurrent setup, a function is logically blocked from proceeding until the tasks it spawned have finished and returned to the spawning scope. This makes it easier to reason sequentially. "finish doing a bunch of tasks, then do this, then do that" etc. The key word here is 'finish'. Not 'spawn a bunch of tasks in the background'. One can then reason about the effect of the function and all its nested tasks as a single unit.

The most elegant example is Occam, where SEQ and PAR are language constructs. (For those interested: http://www.transputer.net/obooks/72-occ-046-00/tuinocc.pdf)