[erlang-questions] Erlang newbie questions

[Richard O'Keefe]

On 18/10/2011, at 9:32 PM, CGS wrote:
> 
> The main point for entering the discussion is the fact that many who replied here were saying that if something crashes in your application doesn't kill your application like in C. I beg to differ on this point. If your Erlang application is single threaded, then your application (I do not speak here about OTP application) will crash if an error occurs there. If you construct your C application like an OTP application, then that means your C applications is multithreaded, so, if one thread dies, it doesn't crash your main application (as well as in OTP application, if one gen_server crashes the whole application doesn't crash).

In C, if one thread goes haywire, it may not *crash* the rest of the program,
but it must be taken as having *corrupted* the rest of the program.

I have often found that a crash in a large C program is due to a bug many source
files away from where the symptom showed up and millions of instructions before.
It's why I tell my software engineering students: "If you can't quickly find out
what caused a problem, try to make it occur earlier.  Use a tracing tool to find
out which functions were called on the path to the symptom.  Add assert()
statements to any of them you've not annotated.  Use any checking tools you
can like splint (static) or valgrind (dynamic) or commercial equivalents (like
Coverity and the Rational tools).  Do your level best to LOCALISE faults, but
expect to fail."

The advantage of Erlang is that one Erlang thread *cannot* corrupt the memory
of another.  More errors are more localised to start with.  (Of course this
applies to CML and Haskell and other languages with immutable data structures.)

Java shares C's problem here.  OK, so you can't construct wild pointers and
scribble all over memory, but Java's reliance on shared *mutable* objects means
that one Java thread *can* corrupt an object that another thread relies on.
And much as I love Smalltalk, Java is just crippled Smalltalk with C syntax and
static typing, and the fundamental semantic problem of mutable objects shared
between threads is at the heart of Smalltalk too.