In a follow-up to his earlier blog post reviewing Joe Armstrong's book, Programming Erlang, Cedric Beust discusses several claims Erlang advocates often make about the language. Beust's verdict on Erlang: the language does not live up to all the claims its supporters make about Erlang's effectiveness to create robust systems.

Regarding scalability, for instance, Beust notes that:

I have always had problems with this claim, and even after reading Armstrong's book, my skepticism has not abated. I can definitely see that the syntax of the language makes it easier to write message-based components which, I agree, are probably easier to scale than locking intensive languages such as Java, but syntax itself is not enough. Just because you write a program in Erlang doesn't mean your code will scale better on multiple processors than if you had written it in Java.

Erlang's notion of lock-free concurrency also does not escape Beust as a claim that's hard to live up to:

I am also beginning to question a few claims that are often tossed around when discussing about Erlang, such as the fact that since Erlang doesn't have any variable nor side effect, it is contention free, and therefore doesn't suffer from lock issues that traditional languages have...

There is one crucial bottleneck that's never even mentioned in the entire book: the message inbox.

The only way a process can modify the state of or talk to another process is by sending a message to that process. Regardless of how lightweight the implementation of this message passing is, there has to be a lock on all these inboxes to guarantee that when dozens of processes send messages to your own process, these messages are delivered and treated in the order they are received from.

In effect, Erlang seems to be moving locks scattered in various places throughout your code (e.g. synchronized blocks in Java) into one single bottleneck. No matter how efficient this bottleneck is, I'm having a hard time imagining that this approach scales as miraculously as Erlang advocates claim. At least, Java gives me complete control on the coarseness of the locks that I use, and also absolute freedom on where I want to place these locks. If an object can be accessed by only two processes, only these two processes will compete for this lock. In Erlang, these two processes will have to pass messages to the inbox of my process, thereby competing with *all* the processes of my application. And since Erlang programmers want you to create as many processes as you possibly can, this can represent a lot of contention and wait times.

Beust also notes that Erlang programs tend to be very slow, and that even when multiple processes are created, the entire computation can be performed only as fast as the slowest component in the system allows.

What do you think about Beust's criticisms of Erlang?