Why Erlang is the best concurrent language available

[Daniel Dudley]

Enlightening stuff, Luke. I particularly liked -- and feel
comfortable with -- your map example, which is reminicent
of "the Prolog way" of processing lists (in most cases).

Yep, your 10 öre was well spent. ;-)

Cheers,
Daniel

----- Original Message -----
From: "Luke Gorrie" <luke@REDACTED>
To: <erlang-questions@REDACTED>
Sent: Friday, January 24, 2003 3:35 PM
Subject: Re: Why Erlang is the best concurrent language available

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