Errr… lang

Erlang is probably the best known product of Ericsson in the realm of software development. It was developed during the nineties for internal use and released to the open source communities after Y2K. It’s name is a word-play: it stands for ERicsson LANGuage, while also paying tribute to the Danish matematician Agner Krarup Erlang, with contribution to the theory of telephone traffic and queueing theory (which plays an important role in the language)

I think there was – and still is – a lot of confusion around Erlang. So what Erlang really is can be sumarized in two bullets:

  • It’s a functional language
  • It provides language level support for massive, thread-based concurrency and fault management

The real problem is that somehow these two things get mixed up and people believe that these features can only exist in connection to each other. Well, that’s not true. As I told my distinguised colleague – and the father of Erlang – Joe Armstrong, they got one thing wrong when they designed the language: the mix-up of the functional nature with concurrency.

I will not debate here the merits or drawbacks of functional programming – there have been a lot of pro and contra arguments that only prove one thing: this is a religious matter. So let’s leave that aside and instead focus on the concurrency aspect.

The support for concurrent programming in Erlang builds on the following constructs:

  • Light-weight, easy (i.e., fast) to create, isolated threads – no shared memory, no implicit dependency between threads
  • Message based, fire and forget communication between threads
  • Fault management hierarchy – processes (lightweight threads) can monitor each other and detect when a certain process has died (through a system generated message)

These simple yet powerful constructs are the ones that make Erlang so compelling for parallel computing – and in no way its functional nature. Exactly the same constructs can be implemented in C++ (or even better Java) – granted, with process mechanisms embedded into the OS kernel in order to secure independence and memory isolation (something that was also implemented within Ericsson). Everything else – functional programming, code hot-swap etc – are of lesser or no importance when it comes to parallel programming.

So, all in all – let’s focus on the real value of Erlang when it comes to parallel programming – and do not mix apples with pears.

One Response to “Errr… lang”

  1. Ulf Wiger says:

    It’s true that many people who comment on different languages on the web have a tendency to get ideas mixed up, and overstate both strengths and weaknesses of various techniques.

    Personally, I voiced my opinion about what constitutes Erlang-style concurrency here:
    http://ulf.wiger.net/weblog/2008/02/06/what-is-erlang-style-concurrency/
    (I didn’t use the F-word once in the article, btw. 😉

    That Sequential Erlang is functional is no coincidence, however. The design of Erlang was the result of several programming language experiments writing telephony control software using different paradigms (OO, logic programming, functional, message passing, etc.) The members of the Computer Science Lab selected techniques that they thought worked well, and experimented until they came up with something that they thought worked well in practice. Some feel that the end result is a thing of beauty. Others disagree. C’est la vie.

    It’s quite possible to write similar frameworks in C++ and Java, and indeed I’ve seen several (as I know you have too). Of the ones I’ve seen, I can’t think of one that I think comes close to Erlang in terms of programmer productivity (and I know you disagree), but that’s of course not proof of anything, except perhaps that these frameworks are extremely difficult to get right. (: