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.
Contributions
Comment feed for ongoing:
From: Terry Jones (@terrycojones) (Oct 03 2009, at 16:25)
If you're interested in learning something about Twisted, a really good series of introductory articles has popped up at http://krondo.com/blog/?page_id=1327
[link]
From: Steve Vinoski (Oct 03 2009, at 16:37)
The Beust Erlang rant is incredibly misinformed; not sure why you highlight it. It imparts nothing of value. He's clearly never used Erlang/OTP for any production systems.
Maintaining trees of supervisors? Gosh, that's really really hard. Generally I spend approximately five minutes out of a multi-month project on supervisor trees. It's trivial. Strike one.
He rants about the syntax. Sigh. No Java programmer should *ever* complain about Erlang syntax. The latter is extremely simple, regular, and, yes, elegant. Unless you're a Prolog developer, you'll find that it's different, but that doesn't make it wrong. This part of the rant alone is more than enough to prove that Cedric has never actually used the language. Strike two.
Error messages are clear once you know the language -- they're just Erlang data structures. The people I work with and I read them and generally know within a few seconds what's wrong. It takes maybe a week at most of using Erlang and reading them to get a good grip how to follow them. Strike three.
No tool support? Bzzt, wrong again. Yes, there's a debugger, but you know what, I've never needed to run it. Never. Three years of Erlang programming and I've never needed the debugger! That's because there's runtime tracing you can enable on the fly, even in production systems, to find any error very quickly. It's far more powerful than any tracing I've ever seen elsewhere. As far as IDEs go, there's ErlIde, which runs in Eclipse -- one of my colleagues uses it and loves it. I'll stick to emacs, thanks, but either way, strike four.
The remark about references, by-value, aliases, etc. and the unsupported pure conjecture that follows stating that it "might end up being just as complex to deal with as the other problems that Erlang is trying to solve" is just so far removed from reality that I can't really comment on it, other than to say that it proves without a single doubt that Cedric has never used Erlang for a real project. He's clearly unqualified to be making these statements and assertions. Strike five.
Cedric, please stop commenting on a language you clearly know almost nothing about. You know Java, you like Java, and your final comment makes it clear you intend to keep using it. So please do so -- we promise we won't bother you -- and stop making up baseless "facts" about Erlang.
[link]
From: Michael Strasser (Oct 03 2009, at 16:43)
You wrote, “I think we’re jointly building something here of lasting value…”
Should not this discussion be moved from a blog to a wiki? Or perhaps a Wave?
[link]
From: JulesLt (Oct 04 2009, at 02:43)
I'd agree that we're unlikely to see anyone not already developing in C languages moving back to C - but better OS and C-level support should make it easier to develop higher level language support.
(The 10.6 implementation of GCD of course also has the kernel-side aspect, which is what lifts this from simply being a thread-pooling library - and it gets more interesting combined with blocks, or Obj-C, because it's then a lot more about firing off jobs of work).
Erik's comment is spot on. I think that's why it's only now we're seeing an interest in real OO languages - it's took Java developers a good decade before there was a real demand for a framework like Spring, which was roughly the same time that people started taking interest in Ruby and Python as alternatives.
While personally I have little problem with 'weird' - curly bracket languages were only something I learnt after, or round the same time, as exposure to Lisp and Prolog, so they don't seen 'natural' to me, they do to a lot of developers - particularly those who took a less academic CS course - and they are the ones who have the votes.
[link]
From: Ryan Dahl (Oct 05 2009, at 04:34)
What about node.js? For the same reasons that Python/Twisted would be the concurrent language of the future, except that node.js is based on javascript - a language built almost specifically to be run on an event loop.
[link]
From: JulesLt (Oct 08 2009, at 01:33)
And lo and behold - a new version of MacRuby which uses GCD/libdispatch to allow you do dispatch Ruby blocks on system threads.
This is where I think it becomes more interesting - as it percolates up into higher-level languages.
(Especially if less crashy than threads have historically proven in Ruby?)
I presume we will see other language bindings shortly - and I wonder if someone will integrate it into other flavours of Ruby (does it really offer any advantage over Ruby's threads if it's only implemented within the Ruby runtime anyway?).
[link]
From: Stefan (Oct 08 2009, at 07:51)
You may want to take a look at GPS (Groovy Parallel Systems):
http://gpars.codehaus.org/ (was
http://code.google.com/p/gparallelizer/ )
[link]
From: mikhailfranco (Oct 08 2009, at 09:42)
And the answer is ....
Scala DSLs generating a new bytecode (POL) for a new parallel VM (CPR)
http://ppl.stanford.edu/wiki/images/9/93/PPL.pdf
Mik
[link]