[kenster07]

It is built with concurrency in mind, from the ground up, making it much easier to write concurrent programs than when using the traditional languages that you've listed.

1) Every process in Erlang manages its own memory and has its own GC. This means that GC'ing one process will not stop the world.

2) Erlang has multicore compatibility baked in, through its process-based model.

3) Erlang enforces pure message-passing at a language level, so there is no shared state. This allows concurrent programs to be written much more easily than in languages where one has to manage shared state.

4) Referential transparency - to the programmer, one can use virtually the same code to pass a message on a remote Erlang process and an Erlang process on the same machine.

5) Fault-tolerant and self-healing mechanisms built in.

This is not an exhaustive list -- it just gives you an idea.

[craigyk]

> 1) Every process in Erlang manages its own memory and has its own GC. This means that GC'ing one process will not stop the world.

Most processes are so short lived, and with message passing, that the GC often might not have to do anything. You just free all memory allocated by processes.

> It is built with concurrency in mind

Like Go on crack. Processes are cheap and are used the same wether they exist on the same machine or a different one. And it has pattern matching.

[kenster07]

Adding to my original post, every process is managed by Erlang's VM. Whereas in many languages, concurrency constructs are mapped to OS threads, Erlang has virtual threads that it manages for you. If the VM detects a multicore processor, it will know how to -automatically- map its virtual threads to take advantage of them.

Also, the actor-based style of programming tends to model real-world interactions more cleanly than OO code, leading to potentially clearer and more maintainable code.