Joe Armstrong's Programming Erlang book was published earlier this year by the Pragmatic Programmers. Erlang has benefitted from renewed interest in recent years, fueled in part by the desire to make better use of concurrent hardware, a task Erlang is especially suited to tackle.

Cedric Beust recently reviewed Armstrong's book, and gave Artima permission to quote at length parts of the review. The full review is available at Erlang.

Beust starts by observing that:

All variables in Erlang are final. Now, this is intriguing and it certainly urged me to read further in order to understand...

Erlang uses an interesting mix of Unification (also called "pattern matching" and used in Prolog, although Erlang doesn't have a "cut" operator) and of functional programming, as found in Lisp, Scheme and Haskell.

These names might be intimidating, especially when used in the same sentence, but I mean this as a compliment: Erlang manages to leverage these arcane concepts in ways that are actually fairly consistent and easy to follow. From that respect, Erlang might be a good language for beginners who want to learn more about unification and functional programming.

The features that generated the most interest about Erlang are related to the language's support for concurrent programming:

What I find interesting in Erlang is that its functional aspect is a means to an end. The idea is that by using standard functional constructs, such as strict evaluation and single assignment, there is no mutable state in Erlang programs, which makes concurrency much easier to implement: imagine being able to spawn thousands of threads without ever having to resort to locking... This is exactly the premise of Erlang...

Avoiding mutable state is one thing, but you also need to have a way to communicate to other processes. This is typically achieved by sharing variables and carefully locking around them so you can't thrash their value, but in Erlang, not only can processes not affect each other, they actually don't have any visibility on their peers, not even their read-only state. When you want to transmit an information to a process, all you know is the id of this process and the data you want to send.

Erlang's syntax to send messages is fairly simple:

Pid ! a_message

Pid is the process, a_message is any valid value (atom, variable, list, etc...). You receive a message with a structure that basically looks like a switch/case:

receive       % receive message sent to this process
   % This is a tuple of a type atom and some data
   {data, Data_content} -> do_something_else(); 
 end.

Erlang includes advanced functionalities to manage the most complex architectures made of hundreds of Erlang processes, among which: handling timeouts, spawning and finding processes, distributing them, notifying one or more processes when one of them dies, etc... Erlang also makes it trivial to send code and functions to remote processes, which opens up a lot of possibilities regarding hot-swapping or live upgrading.

Beust notes, however, that organizing larger Erlang programs can be difficult, because the language does not support classes and more traditional object-oriented constructs. While following a longer code example, Beust remarks:

But what really got my head hurting was the vast amount of repetition that I found in this code. Every listing is basically a clone of the original gen_server code with just a few lines added, removed or altered. This made it very difficult for me to understand what was going on and, worse, to understand the philosophy behind these changes. On the contrary, I found myself having to parse the entire listing over and over again and detect the subtle changes that had been made. And as I progressed through the chapter, I had a clear sense that I was drifting further and further away from the big picture...

This, in turn, led me to wonder what was going on, and I started to realize that Erlang was lacking a fundamental concept that might explain why this code looked so hard to read: Erlang doesn't have the concept of classes...

The problem here is not the absence of classes but of what classes enable, among which polymorphism, inheritance and in more general terms, reusability. As I was going through these repeated listings, I found myself trying to find various ways to refactor them so that only the important part would be shown in the next listing, instead of the entire gen_server. But I couldn't, and I don't believe that it's actually possible in Erlang.

This is a pretty big deal.

Fundamentally, these listings vary in their receive clause and in the various methods they implement. Refactoring a receive clause is like refactoring a switch/case: in general, not very convenient and even if you decide to replace it completely, you need to introduce polymorphism, which Erlang doesn't seem to support at all. Similarly, it doesn't seem possible to override an existing method and specialize it, nor is it possible to add a method to an existing module (or have a module extend an existing one). The closest you can come to with Erlang is by using multiple import statements, which is barely safer than #include.

In a nutshell: Erlang goes to great lengths to make it easy for you to distribute hundreds of pieces of code throughout an entire network, yet makes it nearly impossible to arrange this code in a meaningful way.

In summary, Beust notes that:

The main problem I have with Erlang at the moment is that despite the fact that it was created in 1998 (therefore, after Java, Ruby and Python), the language and its environment feel old. Very old. Most of the examples and listings are run from Erlang's shell and it doesn't seem that there is even a decent editor to help you. Besides the interesting functional/unification approach, the structure of the language is barely above that of C with hardly any means to organize or package your code in a meaningful way. For all I can see, an Erlang program is just a set of methods thrown in different modules, with barely any other interaction besides importing available to them.

No matter how much I admire Erlang's ability to distribute processes across machines, the lesson we learned in the past decade in software engineering is that it's easier to distribute data than code, and Erlang's obsession at sending tiny pieces of beautiful and self-updatable code over the wire therefore appears to be completely misguided. It's already hard enough to achieve this kind of distribution across a LAN, it's simply impossible to achieve in any meaningful way on today's Internet.

What do you think of Erlang?