I checked out the Midori blog: https://joeduffyblog.com/2016/11/30/15-years-of-concurrency/ https://joeduffyblog.com/2016/11/30/15-years-of-concurrency/ > Dev

I checked out the Midori blog: https://joeduffyblog.com/2016/11/30/15-years-of-concurrency/ https://joeduffyblog.com/2016/11/30/15-years-of-concurrency/ > Developers already had several mechanisms for introducing concurrency, and yet struggled to write correct code. > STM could handle all of the decisions transparently like figuring out how coarse- or fine-grained synchronization to use, the contention policies around that synchronization, deadlock detection and prevention, and guarantee that you didn’t forget to lock when accessing a shared data structure. All behind a tantalizingly simple keyword, atomic. > STM also came with simple, more declarative, coordination mechanisms, like orElse. So, although the focus was on eliminating the need to manually manage locking, it also helped evolve synchronization between threads. Fascinating stuff. > Unfortunately, after a few years of prototyping deep runtime, OS, and even hardware support, we abandoned the efforts. Oh well. > It wasn’t even clear that STM would be the correct tool for the job once we got to that point. This is just sour grapes. You already identified the problem and the solution. There's no walking that back. > My brief summary is that it’s more important to encourage good concurrency architecture than it is to make poor ones “just work” We'll I guess there's just nothing to do but leave it to the programmer to get right! Miles ahead? Or DNF?