Why Erlang is the best concurrent language available

[Luke Gorrie]

Matthias Lang <matthias@REDACTED> writes:

>  > > "I build up this list backward, then I reverse it at the
>  > > end, creating an entirely new copy of the list," then it
>  > > *sounds* pretty appalling.
> 
>  > Well, it is appalling. Knowing that recursion "winds up"
>  > before it "winds down", why do it twice when once will
>  > suffice? 
> 
> Because tail recursion allows you to avoid the winding altogether.
> 
> Avoiding the winding is useful because (a) it may help you avoid
> running out of memory and (b) it may be faster.

Efficiency-hack-wise, see also a thread on this list from about a year
ago, where a lot of different implementations of the same stack-using
recursive function were benchmarked. Richard Carlsson summarised the
results in:
http://www.erlang.org/ml-archive/erlang-questions/200110/msg00024.html

But I reckon a seriously cool feature of the Erlang implementation is
that you *can* build up a huge stack and unwind it if you want to,
which tends to be pretty often for me. Consider the implementation of
'map' from lists.erl:

  map(F, [H|T]) ->
      [F(H)|map(F, T)];
  map(_, []) -> [].

This "blindingly obvious" implementation is perfectly correct and
works just fine even for very large lists. It's a very nice way for
code to be, and life is good :-)

Surprisingly this is *not* the case in many implementations of other
languages, even when they have the same recursive programming style as
Erlang, like Scheme and ML. The trouble is that they put artificial
limits on stack usage, so that if you have tens- or hundreds of
thousands of elements in a list (which isn't *that* much), you will
segfault by blowing the stack. Segfault! The accumulator+reverse()
version does work with large lists, however, so you have to use it
even when it's just more coding to say the same thing, unless you can
somehow know that all your list arguments will be small.

So, I reckon it's great that Erlang makes the "blindingly obvious"
code actually work properly, and you don't have to always use fancy
tricks in your "production" code for fear of horrible crashes.

Richard's benchmark suggests you could write a more efficient map
using fancy tricks, but I think this is like the C trick of counting
down towards 0 in 'for' loops to save a comparison instruction: it
might give you the boost you need in a few cases, but it's nice that
most code doesn't need to be written like that.

Just my 10 öre (that's two Australian cents :-))

Cheers,
Luke