Go's concurrency support isn't that exciting. It's basically very efficient UNIX processes. Which is fine, but not as good as composable concurrent state changes, which is what STM offers. (The key is composability; that's what you don't get with locks or "just do it in another process".)

What go has isn't just, "locks or just do it in another process." Either that, or Erlang just has "locks or just do it in another process."

What Rob Pike has put into Go, he used in a previous language he developed called Newsqueak, which enabled him to write an entire GUI windowing system in one afternoon. That combination of shared-nothing concurrency and message passing is pretty darned powerful. In such a system, locks are there under the covers and are invisible to the programmer.

I think you vastly over estimate how much a productivity boost 'shared nothing, message passing' concurrency adds.

I've programmed a lot of both, and while shared nothing makes the easy stuff easier, it doesn't seem to make the hard locking problems any less hard. You still have to think about race conditions and deadlocks.

I think that's an oversimplification. For example, most people do not associate Unix processes with a single address space. In any case, the paper is not asking for a revolutionary threading model.

On the contrary, STM is pretty revolutionary and its exactly what it asks for. :-)