Cédric Beust has an interesting blog post entitled “Clojure, concurrency and silver bullets” where he takes issue with the notion that Clojure can yield code that

is multithread safe and it will automatically scale.

Cédric goes on to state that the concurrency problem doesn’t need a new language as

hundreds of thousands of lines written in C, C++, C#, Java and who knows what other non functional programming languages are running concurrently, and they are doing just fine

In fact, Cédric is quick to point out that Java already has added libraries (in the form of java.util.concurrent) that facilitate easier concurrent coding — and I don’t disagree with him. What’s more, he goes on to point out that Actors aren’t the end-all and be-all of concurrent programming — he even points out an excellent discussion regarding Actors on Stephan Schmidt’s blog entitled “Actor Myths” which is loaded with a fruitful discussion worthy of a close read.

I tend to agree with both Cédric and Stephan — there are no silver bullets which will kill the concurrency werewolf. Yet, I’d like to point out a few things regarding concurrency and specifically actors that might shed some light on why people are espousing something like Clojure and why the Actor Model has gained some mind share.

First, as Herb Sutter noted in his article entitled “The Free Lunch is Over: A Fundamental Turn Toward Concurrency in Software” obtaining an appreciable speed up in application performance requires taking advantage of multi-core chip architectures, which for myriad applications running today isn’t happening. That is, when these applications were written, concurrency wasn’t necessarily tackled, because let’s face it: for the average Joe, thread programming can be difficult to get right.

Accordingly, I suspect that the “thousands of lines written in C, C++, C#, Java and who knows what other non functional programming languages [that] are running concurrently” today were written that way on purpose. These programs were written with threads by smart people. Yet, I’m willing to bet that even those programs have subtle bugs that might not have shown up yet.

These applications (and the authors of them) aren’t going to see things scale up — that is, witnessing a performance increase by throwing better chips or more memory at them (like we could do in the past) won’t help. These applications will instead, need to start running on multi-core chips, where they can begin to take advantage of parallelism (if written correctly to use them!).

Second, threaded programs aren’t terribly difficult to write — no one disputes that — what’s difficult is to get them written correctly. Let’s face it, most testing strategies today rely on deterministic behavior: “given foo, then bar should be 23″. But threads and those nefarious bugs that creep in when shared state and mutability butt heads add inconsistency to this mind set. The phrase “given foo, then bar should be 23″ doesn’t always hold true all of a sudden. Sometimes bar is 89 and other times things blow up or worse lock up and bar is doomed.

Thus, people have started evaluating alternate ways to leverage threads without actually using threads directly because they can be hard to use correctly. If you haven’t read Edward A. Lee’s paper “The Problem with Threads” then go read it now. Mr. Lee does an excellent job of pointing out that our programming model based upon threads doesn’t

vaguely resemble the concurrency of the physical world

Yet, he makes a subtle statement regarding potential solutions that I’m sure Cédric would appreciate:

We should not replace established languages. We should instead build on them.

For some developers the java.util.concurrent library will be good enough, but for others, the Actor Model, which essentially hides locks and synchronized blocks and rather than sharing variables in memory, leverages a mailbox that effectively separates distinct processes from each other. And as it turns out, you can start using Actors in Java quite easily via a number of libraries.

Finally, I suspect that for some people, Clojure and by relation functional programming’s manifestation of concurrent programming is easier to grasp as they resemble “concurrency of the physical world.” For me, Actors embody concurrency in a concrete manner: I can visualize a solution more easily.

There are no silver bullets in software development. Thus, the concurrency werewolf won’t be slain easily; however, the options available to subdue the beast are manifold and those options that provide a concrete model of parallel programming, in my opinion, will be more successful than those that don’t.