Sure, the definition of the "best result" is the question. In short, "the best approach" to me is one that: 1. Is suitable for all sorts of concurrency 2. Ha

Sure, the definition of the "best result" is the question. In short, "the best approach" to me is one that: 1. Is suitable for all sorts of concurrency 2. Has a low memory overhead and low switching costs like the async functions today 3. Is the most "ergonomic" (leading to fewest bugs, easiest debugging and easiest maintenance): yeah, this one is not too well defined either, which is why I would measure developer satisfaction and things like defect rates to establish which one is it, not that this makes it any easier to define :) 4. Provides "enough" safety and encapsulation without impacting performance (much) If 4 has a huge cost, perhaps go with special-cased "async isolated" concurrency primitives when you need added safety in addition to "async", and if the cost is low, allow not paying it anyway with the inverse ("async unsafe"): basically, different defaults depending on what's realistically achievable and nature of the language. I think that ideal lies somewhere near the "non-cooperative multitasking" async programming approach, but I am not sure, and I haven't played with enough recent developments in programming languages either to know if any one of them gets close. But having thought through it a bit with this comment, I think my main gripe is how your (developer's) decision of the concurrency tool (threads, async/await, callbacks, green threads...) affects your syntax simultaneously (eg. why should awaiting a compute-intensive task be problematic? that's an implementation detail a developer should not have to worry about if all else is equal).