[erlang-questions] The future of Erlang and BEAM

[Joe Armstrong]

I'll try and give a short answer to your question.

To start with you are comparing chalk with cheese - Erlang was
NOT designed to be a fast messaging passing language. It was designed
for building fault-tolerant applications - it wasn't designed
for speed it was designed for safety.

A lot of the message passing platforms you read about, and mention in
the same breath as Erlang were designed for speed
and not safety - so it's hardly surprising that is the absence of
errors these other platforms are faster than Erlang.

Where Erlang should excel is when things go wrong - when the
code is buggy and crashes, when the system is overloaded, when you
stress things in unexpected ways.

The Erlang view of the world is very different to the view of
the world used in most other languages.

Take a web server, for example. In the conventional view of the
world if there might be one web server per machine, the
web server might spawn an OS process for each incoming task
(if it wants safety) of it might handle all sessions in the same task
if it wants speed but no safety. It (the web server) uses OS processes
for reasons of safety - to isolate the user sessions from
each other - but this is very slow.

What happens if there is a rare
error in the web-server code itself - one that is very rarely
encountered. Does this affect *all* user sessions or only the
session where the error occurred? - My guess is that all sessions
will collapse if the web-server itself collapses.

How is a web-server in Erlang written? On the face of things it
looks like any other web sever - but an Erlang system that appears
from the outside to be handling (say) 2000 user sessions,
is NOT one web server with 2000 sessions - it is 2000 erlang
process (all independent) and each one is running ONE web server.

So in the Erlang case we have 2000 web servers, each running
one user session - in the conventional case we have one web
server running 2000 sessions.

Back to my question - what happens if there is a rare error
in the web server code itself which is triggered in one session?
In the Erlang case only one web server dies and all the rest
survive. In the case where all 2000 sessions are handled by the
faster server all sessions die.

So you choose - fast or safe? - If you want the fastest possible
solution Erlang is not the answer - BUT it will be unsafe.

Adding checks and recovery mechanism COSTS something.
There are no free lunches.

I often see messaging passing systems mentioned that are said
to have "Erlang like semantics" and are said to be faster.

But these are unsafe systems and Erlang like semantics means
*a lot more* than fast message passing.

Erlang is good at what it was designed to be good at - which was
building fault-tolerant soft real-time distributed systems with
dynamic code upgrade - I know of nothing that has remotely
similar semantics.

There are *many* systems with superficial similarities - but non
that I would trust to build fault-tolerant systems with.

Cheers

/Joe





On Sat, Feb 11, 2012 at 11:34 AM, Radek <poprosturadek@REDACTED> wrote:
> Hello Group,
>
> it's my first post here, although I've been reading many interesting posts
> here for quite a long time.
> Anyway, I posted a question on StackOverflow today with the same title
> (here). As I've written there, I don't want to start any flame-war,
> particularly because I'm actually an Erlang fan-boy :) but I'd like to know
> your opinion on the subject. Here's the original question:
>
> -------
> Some time ago I got seriously interested in Erlang (coming from C++/PHP/Java
> world) - and I've seen it has been successfuly used in the industry, by
> Ericsson, Facebook, Goldman Sachs, etc. So, I thought it would be a great
> platform to build high demanding apps, with low-latency profile, with a lot
> cleaner and nicer language than, for example, Java (for me).
>
> But after "wow effect" has gone, I discovered that there are many high
> performance Java libraries that seem to resolve many problems that Erlang is
> theoretically best suited for (real-time, low-latency applications,
> concurrency, fault-tolerance, etc.). Moreover, it seems that there are
> things that, despite Erlang profile, are just not possible to achieve on
> BEAM (like LMAX Disruptor concurrent framework).
>
> So the question arises: is Erlang still the best platform to build such
> demanding applications ? Wouldn't it be better if we stick to one, very
> mature (J)VM and try to make it even better than trying to achieve something
> similar with less resources available (size of OTP team vs. JVM team,
> supporters, etc) ? And is it possible at all to achieve this kind of
> performance and adoption with BEAM ?
>
> And just to make things clear: I don't want to init a flame war here. I am
> just curious becouse I really like Erlang and I think it's a great platform
> and I'd like to invest time and effort to build real-life projects on it.
> But I'd just like to know what others might say about that and - if I'wrong
> - maybe someone could correct me.
> -------
>
> I hope we can discuss it since I think it would be valuable not only for me.
>
> Greetings,
> Radek
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>