This subject seems to have hit a nerve, and there’s been outstanding feedback in the comments. Some of it makes a good case for changes in the series articles, and others just need more attention than I think they’ll get down in the comment section.

[This is part of the Concur.next series. To avoid this getting too meta, maybe confine your comments & contributions to one of the mainstream articles in this series, as opposed to comments on comments on comments here?]

Python/Twisted · Terry Jones argues that this combo is a winner for asyc event-driven systems. I’m not sure it’s sufficiently accessible to mainstream programmers, but it’d surprise me not at all if the Java of Concurrency ended up being a library or framework building on an existing mainstream language.

GCD/Libdispatch · Several people pointed at Apple’s new Grand Central Dispatch, the libdispatch layer of which has been open-sourced. (Reading about GCD makes me think of java.util.concurrent.)

While I’m open to the idea of library-based solutions to these problems, I really doubt that the application programmers of the future are going to return to any flavor of C. Second, unless I’m misreading things, GCD handles the case of a bunch of things needing sequential access to a single resource, as well as things that can run entirely in parallel. My instinct is that there are a lot of application situations where the concurrency problems don’t fall into either of those neat baskets.

But I’d love to be proved wrong.

Biases · Wes Felter suggests I have a Web bias, since I don’t mention any of OpenCL, OpenMP, Cilk++, Ct, TBB, GCD, and so on.

Guilty as charged, in particular if you change “Web” to “Net”. If you want to do vectorized computation, particularly in one of the C languages, there are some pretty good tools. I think there’s a big interesting problem space where this kind of thing doesn’t help. I also freely admit to not even recognizing some of those acronyms; if the Java of concurrency is lurking inside one of those, somebody needs to write an educated post explaining why, and I’ll link to it.

Bob Foster accuses me of Java-centric bias, asking “what about F#, Axum, LINQ (and DryadLINQ)”.

Rich Hickey, AKA the Clojure Guy, suggests at length that I’m biased toward Erlang, and makes some good points too; follow that link.

I think I’d better write another short piece in this series laying my own biases and viewpoints. This is a blog, right, and there’s no point pretending I’m neutral, but I should at least be transparent.

Save the Earth · Greg Pfister, who writes a lot about this area, says that you get a net saving in energy per unit of computation done by running the computation on multiple low-gigahertz/watt processors. That could be a really big deal.

Erlang Ecch · Cedric Beust offers a rant as to why Erlang is not the way forward, which I’ll just link to without further comment. [Update: Steve Vinoski fires back below in the comments.]

Why Java? · I find the comments on the Java piece instructive and amusing too; they offer a bucket-load of other reasons why it was that Java went over the top, notably including JDBC and applets. But the one that really made nod was from Erik Engbrecht:

I'd like to add that Java lacks any sort of language-level metaprogramming system and has highly regular, inflexible syntax. To get Java, you basically take Smalltalk and remove all of the powerful concepts from it while leaving in the benign ones that everyday developers use. I think there's something to be learned from that.

Laundry List Diffs · Steve Vinoski points out that I left out distribution, required at least for reliability and for lots of other stuff these days. I think he’s right.

There was some discussion of the whole Tail Call thing and I increasingly think it’s orthogonal to this debate, so unless someone has a good reason for disagreeing, I’ll toss it out.

Oops, I was wrong, Haskell compiles to native code as opposed to using a VM.

Keep ’em Coming · I think we’re jointly building something here of lasting value that might be really beneficial to whichever bright creative software person eventually runs out of patience and ends up building whatever it is we need to make things run better in a concurrent world.