I don't think threads are that hard if you're in a language that provides the right tools and has relative few footguns (e.g. Java) In Python or C++ God help you.

Even in Java you have to stick to java.util.concurrent, avoid synchronized and use Executors whenever you can.

This post does a fantastic job of laying out the reasoning and implementation of various concurrency methods and their trade-offs. It is one of the rare nuanced views on async/await vs green threads. Plus it makes the links between CPS, delimited continuations and effects, thus generalizing concurrency into one of several possible "stackful" operations.

In terms of ocaml and the authors concerns about continuation capturing and memory/performance, this is a good paper - http://manticore.cs.uchicago.edu/papers/pldi20-stacks-n-cont...

I think the _only_ thing the author didn't cover about concurrency is that "waiting for one of several things to complete" is a powerful primitive for concurrency that very few platforms provide direct access to. I.e. most async event loops are powered by OS primitives that allow such "heterogenous selects" and they are used under the hood but not exposed. I think Go's select, Tokio's equivalent, ConcurrentMLs/Racket more powerful choice operator. All of these allow expressing some nice patterns that other languages make impossible (sad Promise.race) or not user facing (cancellation in structured concurrency)

Great job!