Erlang, pros and cons

Erlang programming language was controversial since it was created in Ericsson,
as super-reliable platform for telephone exchange devices.
With syntax of Prolog, and unique semantics similar to Lisp,
it was a puzzle for everybody. Yet, it has proven to be so reliable,
that they could not even measure downtime. No downtime for years.

There is another side-effect of Erlang's simple functional design: it is very optimal
for parallel processing. So, the language is recently re-discovered, and used in some
prominent projects, including CouchDB.

For example, a "process" in Erlang takes about KB of memory,
and a "thread" in .NET takes about MB of memory. And Erlang process provides insulation of data,
and .NET (or Java) thread does not. Huge difference.

After initial success, the other side of Erlang become evident: it is not very efficient
for common tasks such as processing text. For document-oriented database that could be a problem.
In particular when competition tools, usually written in C/C++ are more efficient.

So, CouchDB creator is on his new quest, to port portions of the system to C/C++,
and keep Erlang for what is it good for.

This presentation provides nice overview of pluses and minuses of Erlang.
The conclusion is that "strange syntax" is main reason for relatively small adoption,
and consequently lack of investment (and results) in performance optimization.


Erlang, the Language from the Future?
Presented by Damien Katz on Aug 28, 2012

Damien Katz Abandons Apache CouchDB, Continues with Couchbase Server

What Sucks About Erlang by DAMIEN KATZ

On the other side, some people try to take "right tool for the job", and are attempting to use
Erlang for coordination and monitoring other tools.

podcast: Alex Robson about polyglot programming @ .NET rocks

In Erlang, "failure" is "normal" and planned for. Each process is designed to detect and handle
failure of monitored processes, and "tree" of processes is self-healing, where failed processes are detected and replaced automatically. Since there is no shared state, only messaging, it is not hard to scale system, and make it reliable...
...