Notes on structured concurrency, or: Go statement considered harmful (vorpus.org)

> Annoyingly, though, there is no standard name for this category of control flow constructs.

That is wrong.

There is a standard name: FORK. In 1963-11, in "A Multiprocessor System Design", Melvin E. Conway introduced the terms FORK and JOIN. A few months earlier, he had introduced the term "coroutine".

The UNIX operating system hijacked the term FORK, and later the POSIX threads API hijacked the term JOIN in "pthread_join".

However, the original JOIN was something far more useful than the POSIX pthread_join. Also, while modern programmers hearing about "fork" tend to think about UNIX, the original FORK was something more general and easier to use than the UNIX "fork". Variants of the original FORK exist in a large number of programming languages, including Occam, Ada, OpenMP etc., using various keywords.

The Go language "go" already existed in 1964, in the programming language IBM PL/I. In PL/I, the equivalent of Go "func(...)" was "CALL func(...)", while the equivalent of Go "go func(...)" was "CALL func(...)TASK".

In programming, very few really new things appear. Most so-called "new" things are just fancy new names for ancient and forgotten things.

The post advocates for structured concurrency, but it compares a language primitive with a library abstraction. In Go, implementing the same basic nursery concept is straightforward with `golang.org/x/sync/errgroup`:

  g, ctx := errgroup.WithContext(ctx)

  g.Go(func() error {
    return task1(ctx)
  })

  g.Go(func() error {
    return task2(ctx)
  })

  return g.Wait()

If you don't care about error propagation or cancellation at all, the standard library also provides `sync.WaitGroup`.

The author also seems to argue that structured concurrency is always preferable, but I do not think that is true. There are valid use cases for unstructured concurrency, particularly for long-lived or independently managed tasks.