ReRe: why isolated components

[Joe Armstrong]

> > > but is that the motivation for the wrapper project?
> > 
> > Well, *that* is another issue.
> > 
> > I don't know Joe's thoughts on the subject, but my impression is that 
> > it's about coping with failures.
  
Yes

> > If a subroutine crashes, or if it just detects an abnormal condition and 
> > logs it, this is behaviour that punches right through to the top levels 
> > of the application. The "let it crash" philosophy of Erlang says: if a 
> > component fails, let if fail, and don't burden the caller (or service 
> > requester or whatever you name it) with analysis of the crash details, 
> > just tell it that the request failed.
> > The toplevel may be unable to cope with the situation, but then passing 
> > up crash details will introduce lots of coupling just for the rare case 
> > of a crash - the resulting design mess just isn't worth the benefits.

Processes that fail if they can't do what they are supposed to do
are  called "fail-stop" - this is how the Tandem computer was designed.

I recentely read the amazingly good:

@techreport{gray,
        author = "Jim Gray",
        title = "Why do computers stop and what can be done about it?",
        type = "Technical Report",
        number = "85.7",
        institution = "Tandem Computers",
        year = 1985
}

It was like reading a description of Erlang.

One way to describe Erlang and OTP is "It's just like the tandem - only in 
software instead of hardware"


> > 
> > Other languages handle this via exceptions.
> > Eiffel got this right: Eiffel exceptions are unsuitable for passing up 
> > information on a crash (apart from diagnostic information that helps 
> > programmers and debuggers; there's no channel for passing up information 
> > that would help the top-level to analyze the error).

Yes - as well as isolation you need, what schneider calls

"Failure-reason"


> > Java and C++ got it wrong: they make it all too easy to pass up 
> > information that allows the caller to continue. The net result being 
> > that exceptions create an additional, quite tight coupling between low 
> > and high levels of the system. (It's no good if the top-level of a 
> > system tries to handle an InternetConnectionFailure exception just 
> > because an Internet resource wasn't available ten call levels below it...)
> > 

Shudder

> > Erlang's idea is to separate the layers of processing into separate 
> > processes, and to let the process crash. The advantage is that this 
> > quite nicely handles any memory leaks that might occur on lower levels 
> > (even garbage-collected languages can leak memory: when calling out into 
> > C, or when accumulating larger and larger structures).
> > I consider it a disadvantage that this interleaves the issues of crash 
> > protection and asynchronous message passing. 

I beg to differ :-)

> However, my Erlang 
> > experience is *very* limited, so please consider the latter just an 
> > uninformed opinion.
> > 
> > HTH
> > Jo
> > 
>