I think this guy was too kind to STM. Otherwise I largely agree.<p>Despite being a C++ programmer I like using high level abstraction. I like being able to write a few lines and knowing what the result will be and having the computer just figure it out the details. Despite that I really want those abstractions to be as close to zero cost as possible. I also want to precisely know how to work with the contract the spec demands and the implementation reality requires, because performance is all too often a real concern for me.<p>STM has never had a role in any of that because it tries to be a panacea. It tries to fix everything for everybody. There is no way it can be an optimal (or even reasonable) solution for most problems).<p>I think me and the author would agree that naked mutexes are the gotos of threaded algorithms. Just as we replaced gotos with several kinds of loops, several kinds of functions, classes, lambdas and countless other more expressive tools, we will replace naked mutexes with a host of other tools. Have something you just want to run on some other hardware and get the answer from, try a future/promise. Have N units or identical work, try a parallel for or a one of the many GPU executors. Have a complex dependency chain of heterogeneous work, build a DAG of actors or other automata. Need something else, perhaps your threading primitive hasn't been invented yet.
I'm not optimistic about the kinds of approaches mentioned fostering "ubiquitous parallelism." Just as a better compiler, language, or implementation technique won't make a bubble-sort into a quicksort, I don't expect them to turn essentially sequential programs into parallel ones. We need new kinds of algorithms, not better programming techniques. Being explicit and telling the compiler all about isolated pockets of dependencies does not ultimately defeat their constraints on the overall program. I remember a statement by Knuth in an interview[1]: "Let me put it this way: During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading."<p>[1]: <a href="http://www.informit.com/articles/article.aspx?p=1193856" rel="nofollow">http://www.informit.com/articles/article.aspx?p=1193856</a>