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.

I don't know of another language that put fault tolerance as top item on the design "todo" list. Erlang did that. Processes are lightweight (only a few KB overhead each). Processes have isolated heaps, much like OS processes in fact. That is rather unique. People who have been burned by large concurrent C++ programs crashing with segfaults, dangling pointers and rare race conditions stemming form concurrency units (callback chains, threads) stepping each others' toes, will appreciate that.

Its VM is rather elegant and powerful. It is a marvel of engineering if you wish. O

Even though rather advanced, I would suggest reading blog posts by Jesper Louis Andersen he covers some of these topics at the level I like.

http://jlouisramblings.blogspot.com/

The books are also good. There is also Learn You Some Erlang book, I even have the dead tree version of it (but there is a free online version as well). That also touches on some uses.

I think it makes more sense to think of erlang like a cluster machine and fault-tolerant operating system that comes with one programming language (two, if you count elixir).

If "cluster OS" or "this thing needs to keep running for 10 years straight, even through software upgrades" sounds like it addresses problems you face, then look into erlang.

If not, then you'll probably find it cool, but not particularly useful.

In addition to the points already mentioned by others, it has a really elegant syntax which mirrors Haskell while maintaining accessibility.

Yes! Just look at the code required to serialize objects, send them between 2 computers, and deserialize them. You would need to do all of that stuff manually. Even with a library like AKKA, I don't think it's nearly as simple as it is in Erlang: 1 line to connect, 1 line to do the remote call.

In Erlang you can remote into servers, examine their message queues, update the running processes with new functions, etc. You can guess what that would take with those other languages.

You could roll your own supervisor process and have things automatically restarted when you lose connection to them in the other languages, but it's already baked into Erlang.