Concurrency.next and the suckiness of explicit concurrency management

Tim Bray has a nice blog (with lots of fun comments) about multicore chips, parallelization and concurrency, and how this may bring about a new set of popular languages. Nice analysis, most of it makes sense.

But what he said last struck me the most, because it's been bothering me for a while too and I thought I was a loner.

Assumption · I’m taking the following as an axiom: Exposing real pre-emptive threading with shared mutable data structures to application programmers is wrong. Once you get past Doug Lea, Brian Goetz, and a few people who write operating systems and database kernels for a living, it gets very hard to find humans who can actually reason about threads well enough to be usefully productive.

When I give talks about this stuff, I assert that threads are a recipe for deadlocks, race conditions, horrible non-reproducible bugs that take endless pain to find, and hard-to-diagnose performance problems. Nobody ever pushes back.

When I started working NetBeans, where you the coder are responsible for concurrency, rather than the app server container, I was stunned, literally stunned, at how ugly things could get so easily. I almost immediately introduced deadlocks, data corruptions, and other icky stuff, and found myself desperately reading the bibles on concurrency and thread safety.

But I also found myself shaking my head. Why are we all doing this as if it makes sense for programmers to have to worry about this. This level of complexity and shooting-yourself-in-the-footedness indicates to me something inherently wrong with the programming model. It's like a hotel asking arriving guests to coordinate with each other to assign themselves rooms.

I had heard about the asynchronous, immutable state, message passing model of Erlang and Scala, and these seemed to me what we were looking for. You write an actor, it does what it does, and doesn't share its state with anyone except through copies. Simple, nice, elegant, parallelizable.

It's very hard to move from one language to another, so I'm with Java for now, but I'm looking forward to an opportunity to try out Scala or Erlang for Real Work. I'm sure the opportunity will come soon enough.

It's kind of nice that the new chip architectures are forcing programmers to think about parallelism, and thus good parallel concurrency models, and thus looking at the asynchronous/message-passing architectures of Scala and Erlang. Maybe we'll get out of this synchronized-volatile-deadlock-semaphore-thread-pool-latch madness that exists today in Java.