It's interesting that you choose Swift as an example, because I think in some ways Swift does a poor job of accommodating async using the "bubble wrap" approach

It's interesting that you choose Swift as an example, because I think in some ways Swift does a poor job of accommodating async using the "bubble wrap" approach. Specifically I am talking about the default of using atomic reference counting on all references. This makes it somewhat idiot proof at least with respect to avoiding NPE's, but it comes at a huge performance cost (especially on x86 which I guess is becoming less of a concern for Swift code). I think this is a fundamental issue: a big part of the benefit of concurrency and parallelism is supposed to be increased performance. However a lot of the ways to make concurrency "generally safe" tend to hamstring performance, because you have to protect against all the different types od errors programmers can make, which basically means a lot of expensive synchronization. Maybe there is a way to hide this completely, as you say, in a performant way. To do this, I think you would almost have to have either some kind of really clever risk-free data structures, or else a very smart compiler. Another approach might be to keep concurrency at arms length from the average programmer. I.e. hide 90% of it inside of libraries, and expose safe interfaces which the programmer interacts with in a mostly synchronous way.