[erlang-questions] Erlang newbie questions

[CGS]

Hmm... "Bad boy C! Let's kill it! Hurray! Down with C!" Or maybe we 
already forgot the small and funny poetry "let it be written in C"...





On 10/19/2011 11:18 PM, Richard O'Keefe wrote:
> 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.
>
>
>