Erlang's change of fortunes

Today morning I had a conversation with my distinguished colleague Stefan Z. while hanging out at the coffee-vending machine in the tea-kitchen at our client's office. As we are both working for the telecom industry, we came to discuss Erlang. No, not that celebrated guy, but a rather obscure programming language designed at the Ericsson Corporation.

For the fun of it, let's first look at some snippets of Erlang code!

define a data structure:

  Student={person,{name,{first,yakkety},{last,yak}},{footsize,1}}.

access a member of data struct (by pattern matching, cool!!!):

  {_,{_,{_,HisName},_},_} = Student.

printing yakkety:

  io:fwrite("his name is: ~w~n", [HisName]).

define a list:

  Fruits = [{apples,10},{pears,6},{prunes,3}].

append something to a list:

  Fruits1 = [{oranges,4},{lemons,1}  Fruits].

get the head of the list (by pattern matching, cool!!!):

  [ListHeadFruits2] = Fruits1.

simple function:

  incr(Num) -> Num + 1.

recursive function:

  fac(0) -> 1;
  fac(Num) when Nun > 0 -> N * fac(Num-1).

infinite loop receiving messages (by pattern matching, cool!!!) and sending responses back (by the !operator):

  loop() ->
      receive
          {From, {request, Param1, Param2}} ->
              From ! {self(), Param1 + Param2},
              loop();
       end.

a foreach loop (note the lambda function definition between fun and end!):

  extract2ndElements(List) ->
      lists:map(fun({_,Second}) -> Second end, List).

Ok, it was fun, but we mustn't digress too much...

Erlang in itself is rather a paradox: you normally associate Telco equipment programming with the lowest of the lowest: asm, C99 or EC++ (castrated C++). Now, there come some guys in the 80-ties and to the corporate management they can sell a functional language for this task! This alone is incredible! But wait, there's more! Up to now Erlang was a niche language used quite exclusively at Ericsson. Now this seems to be changing. But first we need some history.

In the 80-ties Erlag was designed to be slow but reliable. This is due to the very nature of the functional languages: you don't have shared state, no side effects, all data is copied between functions. For safety's sake even the variables can be assigned only once! If you apply that to parallel computing, you don't have to worry about synchronization and critical sections - the "share nothing semantics". But it will be rather slow. In this case it was a deliberate decision: they wanted not simply a reliable language, but a "highly reliable language"! And a distributed one. So to speak a natural fit for the Telco environment. As an example: the AXD301 switch achieved the incredible 99,9999999% realiability! It's 9 nines availability! And we were struggling to achieve 5 nines* availability with C++ on CarrierGrade, High Avalability (HA) Linux and a custom HA-middelware platform in my last project! By the way, the AXD301 software has 1.7 million lines of Erlang, making it the largest functional program ever written**! Really impressive stuff IMHO.

I guess you have read (or heard about) Herb Sutter's article titled "The free lunch is over"***. So you know that the "next big thing" in software is supposed to be multicore scalability. So hear up now: as the multicores are comming pretty cheap now, Erlang can be at last both fast and reliable as it can be easily distributed on several cores! It's definitely good news! We've seen the incredible reliability which can be achieved, and have a natural programming model for distributed computation. Why? In short, as there is no shared data:

1. programs are easily distributable,


2. easily made fault tolerant by composing them from worker and observer processes,


3. easily made scalable (because of 1. we simply add more processors).**

So could distributed computing be the saviour of the functional programming? Think about Google's MapReduce!

---
* For those not working with HA systems:

      Availability%   Downtime per year
      99.9999            30 seconds !!!!
      99.999              5 minutes
      99.99                50 minutes
      99.9                  9 hours

** says Phillip Wadler: http://wadler.blogspot.com/2005/05/concurrency-oriented-programming-in.html

*** on DDJ or www.gotw.ca/publications/concurrency-ddj.htm