His point that Clojure will prove almost as difficult as Java because you have to figure out what to make REFs of seems wrong to me. He is missing the point that the remaining stuff in Clojure is purely functional, and therefore really nothing like Java.
Indeed. The most difficult thing about concurrency in Java to me is that mutability is idiomatic in the language. The fact that you have to use refs to mutate state in Clojure has provided me incentive to find functional ways to write code.
Scala is the clear king of speed. Actors are more lightweight than threads, and a shared nothing approach means no locking, so concurrency can be maximized.
Ah, another person who's never come close to examining Scala's actor implementation. Check out scala.actors.FJTaskScheduler2. It uses threads. That's, uh, kind of the only way to get a JVM process to do things concurrently.
To compare apples to apples, Clojure's agents are also allocated from a thread pool allowing many agents per thread. I'd imagine you'd see similar performance between the two.
Actors are decoupled from the means by which they are executed. Scala has a nice system where you can run thousands of event-based actors in a thread pool. It grows the pool as needed (as threads block). See http://www.scala-lang.org/node/242
While it may use threads, Scala's actor system effectively allows you to create thousands of actors.
Kilim is actually a pure (depending on whether you see a byte-code processing system as pure) Java system that does the same thing (as far as I can tell): http://www.malhar.net/sriram/kilim/
The author makes the mistake of assuming that STM is the only/primary concurrency control mechanism in Clojure. Agents and atoms provide additional control mechanisms that are appropriate for different situations.
Given a quick read over the article and comments, and a small amount of personal clojure experience, it seems to me that this is a poorly researched article. The visualizations may be easy to understand, but they are based more on assumptions and misunderstanding than on reasoned fact.
In particular, the author's concern regarding management of mutable data structures in STM is almost bizzare. The concurrent code that I have worked with uses persistent but immutable data structures across agents, which are execution blocks queued in a thread pool. Using this you can write large pieces of code without dosync that scale to any number of cores in an efficient manner.
So, while I enjoy comparisons and nice visualizations, maybe someone else could try their hand at this one?
Clojure offers three concurrency mechanisms: agents, atoms and refs. Agents are atoms are very easy to use and understand. They are no more complicated than Scala's actors.
Clojure's refs are more complicated than Scala's actors, but Scala has no similar feature. If a Scala programmer needs the functionality in Clojure's refs, then the Scala programmer must use plain old Java concurrency.
IMHO, there are three groups: 1. Haven't done complex concurrency. 2. Hates threads/concurrency. 3. Pain lovers.
Erlang is on my to-learn list, maybe that will change my opinion.
(I am currently updating my very rusty lisp (inspired by a comment on HN, btw). Gambit Scheme had some lib inspired by Erlang. I'll read that and maybe learn enough to have an opinion.)
The Gambit Scheme lib you're talking about might just be termite (http://code.google.com/p/termite/). It sounds like an interesting lib, although it doesn't do everything Erlang does.
"By reusability, I mean is how reusable (composable) is a piece of concurrent code that you write with each of these languages/paradigms? In the case of Java, it is almost never reusable unless it is completely encapsulated."
How is this for reuse in Java? (And do note the "state" field...)
