This is a fascinating account of the difficulties involved in implementing STM, written by someone who worked on the problem for several years and ended up disillusioned about it. The article is unusual, even highly unusual, in how frank and substantive it is. (By "substantive" I mean grounded in experience.) People nearly always argue for or against things like STM based on whether or not they like the idea, which leads to a lot of (not necessarily intentional) hype/FUD. By contrast, this article contains hard-won intellectual honesty. The author worked hard on the problem with a smart team for a long time, so the fact that he was forced to change his mind is significant. I'm glad I read it through; it gets more readable (and more dramatic) towards the end.

I don't understand all the details, but the three "disillusionments" that end up knocking their efforts off the rails seem surprisingly obvious. These are: (1) what if a transaction contains code that talks to an external system; (2) what if non-transactional and transactional code write to some location at the same time; and (3) what if code reads a write that was performed by a failed transaction but hasn't yet been rolled back. Design problems are always more obvious in hindsight, of course, but surely these issues were known?

Another question I have: what's different about Clojure's and Haskell's STMs that allow them to escape the same fate (if they do)?