> Note that the order of the definitions is important: had we moved our base case at the bottom, the recursion would never finish because map(F, [H|T]) would always match (remember? an empty list is also a list with a head and a tail).

Which confuses me a bit, since I am used to the empty list not having a head (I am thinking for example of Haskell). Is it true that in Erland the empty list has a head? And what would it be? Some generic null object?

For readability, it's nice to have the base case at the top. For performance (if performance is an issue) it's nice to have the base case at the bottom since all function heads are evaluated in order.

If you're looping over a million element list and your base case is first, it'll be checked a million times. If your base case is last, it'll only be checked once when your normal cases no longer match.

And to clear up your confusion, the writeup is wrong about empty lists matching on [H|T]:

The BEAM virtual machine is able to reorder most clauses based on need, and for most cases, a binary search will be done through all clauses. Exceptions include function clauses with guards, which cannot easily be reordered but still impact whether a clause will be used or not.

The VM will instead try to reorder the clauses up until the next guard clause, if possible.

You should mostly care about writing readable code and let the compiler and the VM do the rest.

I must shamelessly say it seems to have aged reasonably well, unlike some other things I wrote I actually read it now with interest, especially I haven't dabbled in Erlang since and forgot some details.

I recommend everyone who finds fun in programming to give Erlang a shot, I don't think it's great for all the use cases (what is?), but, for example, for writing servers of all kinds it's totally awesome, especially with OTP, which I didn't cover in my tutorial. It's also completely different from everything else, even if you know Prolog or Haskell/ML, which are related in some ways. One day I would really like to get myself together and write something like a game server for poker or bridge in it.

Erlang VM is built on the premise that it runs a functional language. I would argue that it will be extremely inefficient to implement non-function language to run on Erlang VM. By non-functional I mean language that is based on mutable and shared state. You can look at Elixir (http://elixir-lang.org/) to see great example of an alternative language that runs natively on Erlang VM. While offering syntax that is more familiar to many people Elixir retains all basic restrictions of Erlang.

One of main contributors to Erlang is Kostis Sagonas from Athens National Technical University. He is one of the main contributors to HiPE (the native code compiler), and creator of PropEr (property based tester).