The Disco Blog

Concurrency is hard. A language’s implementation of concurrency concerns can make the challenge of dealing with concurrency even more difficult or a bit easier. Case in point: Erlang. Erlang is a hip functional language, developed by Joe Armstrong of Ericsson in the 1980s that explicitly facilitates concurrent programming by enabling distinct parallel processes (as opposed to threads) which communicate via message passing (rather than shared memory). Thus, in Erland, there are no locks or the need to declare synchronization as there is no notion of shared memory, like there is in Java (or C#, for that matter).

The question then remains for those who are Java developers: why should I care? For starters, because it’s my bag, it is undoubtedly interesting to see how Erlang is so vastly different than everyday Java. Not only is the language functional in nature (like Haskell), but it’s also type-less (that is, types are inferred at runtime like with Ruby, for instance). Because the language was built for parallel computing, it does some interesting things that have correlation back to Java– for instance, in Erlang, all variables are essentially final once declared. Thus, Erlang doesn’t support mutable state. As anyone who’s ever coded in Java knows, mutability, while intrinsically supported by Java, can easily create nefarious defects, even in non-threaded code.

But I think the author, Joe Armstrong, does a great job of stating why one should care about Erlang. In chapter 1, a rhetorical question is posted asking “what all this about?”– Joe’s response sums it up quite nicely:

It’s about programming a distributed concurrent system without locks and mutexes but using only pure message passing. It’s about speeding up your programs on multicore CPUs…it’s about designing methods and behaviors for writing fault-tolerant and distributed systems. It’s about modeling concurrency and mapping those models onto computer programs…

All in all, I enjoyed this book– I certainly learned an interesting language that has a long history of production use. It’s a big book (500+ pages including documentation) and I did find myself skipping a few chapters here and there– for instance, there is an entire chapter devoted to a custom database developed for Erlang (my thought being that if I need a database for an Erlang application, I’ll use a language bridge to leverage an everyday RDBMS).

Learning a new language is always helpful, man; in fact, I took my own advice, as I wrote years ago, those that learn new languages:

travel the IT world more freely than do monolinguists (sure that they can apply their skills in any environment), and they also tend to better appreciate the programming language called home, because among other things they know the roots from which that home is sprung.

Next language to learn? Scala, baby!