Notes on structured concurrency, or: Go statement considered harmful

http://kimundi.github.io/scoped-threadpool-rs/scoped_threadp...

EDIT: He compares to Rust in a comment on the Reddit thread:

https://www.reddit.com/r/programming/comments/8es8x3/notes_o...

As an aside, HN users tend to sneer at Reddit, but this is another case where the discussion on Reddit is better than the one here.

A question I had was with the API that's been chosen. The `nursery` is chosen as the reified object, and a function `start_soon` is exposed on it. Perhaps in other parts of the library there are other methods exposed on `nursery`? If not, in some languages it seems like the `start_soon` method itself would make more sense as the thing to expose. In use, it might do like this:

    ...
    nusery {
      (go) in
      go { this_runs_concurrently_in_the_nursery }
      go { this_also_runs_concurrently_in_nursery }
      // make a regular function call passing it the nursery's `go`
      some_func(go)
    }
    ...

    ...
    func some_func(go) {
      do_something()
      go {
        nursery {
          // This nursery is within the outer one.
          (go2) in
          go2 { do_stuff }
          go2 { do_more_stuff }
        }
      }
    }
    ...

Let me try with something else.

Imagine you have try/catch/finally BUT NOT AS CONTROL FLOW CONSTRUCS but "just api calls".

So, you language need to be used like:

    foo()
    exceptions.try{
    	bar()
    	this.catch{
    	
    	}
    }

Imagine how bad this could be. If only "try/catch" was as with "IF/ELSE/ENDIF" so you not do something stupid like:

    foo()
    exceptions.catch{
    	what?()
    }
    bar()

I am being misinterpreted here (in a peculiar way that has happened before on HN...). I wrote that it does not increase the complexity "in any measurable fashion".

It seems that you interpreted this as "concurrency is less complex than non-concurrency", when in reality I am saying "concurrency is a tiny bit more complex than non-concurrency" (extra emphasis on "tiny").

Now, back to the topic:

Asynchronous programming is strictly speaking the simple idea that code will be run later when some conditions are met. For example, running a callback when a network response is received from the "fetch" API in modern JS, with all I/O handled behind the scenes by an event engine of sorts.

I do not believe that this concept provides any measurable increase in cognitive load. You only concern yourself with these devices where they are used, and they are extremely simple to wrap your head around.

In another model, you may have full parallelism and shared memory access, in which case you need to be more careful to only use thread safe structures. Even then, unless you do something stupid™, everything is fine, and the cognitive load is increased globally but only mildly so with a model similar to goroutines and channels.

Finally, you may have to design and use synchronized/atomic data structures, in which case things increase in difficulty. While this does increase cognitive load in a small area of the code, I does not increase the cognitive load over the entire application. However, just like not all application need to design a cryptographic protocol, not all applications need to design concurrent data structures even if it uses concurrency. Thus, one should additionally note that this localized overhead is not a universal overhead of all concurrent programming.

BTW, I do not find that goroutines present less cognitive load than pthreads ("threading") and a CSP library. They simply present syntactic sugar for a better developer experience. They also give an M:N threading implementation unlike pthreads, but that's an implementation detail.