[erlang-questions] Erlang newbie questions

Jesper Louis Andersen <>
Tue Oct 18 00:18:17 CEST 2011


On Mon, Oct 17, 2011 at 23:14, Gerry Weaver <> wrote:

[...]

> For example, if you have a network server and the listener process fails, how do you recover? It seems that the fault tolerance is only applicable in the VM context. This is, in my mind equivalent to any other application process. If I have a network server written in C, I can have a watchdog process to kill and/or restart it in the event of failure. The C based approach actually seems more robust.

There is a distinct, subtle difference here. C programs tend to be an
all or nothing approach. If there is a mistake in the C server, then
it doesn't matter where that error happen. It can be in the parsing of
a configuration file when you send it a SIGHUP or something such. This
will kill the C server, all its internal state, all undergoing
transactions, all connections currently on the server and more. That
is, either the C program runs and you are happy, or it doesn't run and
you have trouble.

Erlang has, due to process isolation, the ability to subdivide the
server into smaller compartments. An error in one of these will in
general not take down the whole server. Like you say, it is rarely the
listen loop itself which has the error. It is often something else.
Here, Erlang has a built-in mechanism for ditching a wrong or faulty
TCP socket without affecting the other connections. So you can say
that in Erlang systems, it is not an all-or-nothing approach but more
fine grained. The point is that the isolation lets you segment your
program such that errors can not propagate uncontrolled from any
system to any system.

The other subtle difference is that in C, you trade execution speed
for safety. C programs are not safe. They segfault rather than raise
error. Now, if you have the time and effort to build your program
well, it can become robust and stable. But the point is that you will
be able to get to that same level of robustness in Erlang for a
fraction of the effort. And in addition, Erlang programs tend to run
really fast when concurrency and distribution is involved - you need
to beat the Erlang VM, a system with well over 15 years of
optimization.

Finally, there is the point that Erlang is a way better language than
C. C is an excellent language if you need an imperative simple
language. But if you need abstraction, it is notoriously bad. Erlang,
with a proper lambda calculus base, fares much better there.


-- 
J.



More information about the erlang-questions mailing list