Well, well...

[Sean Kelly]

Robert Fraser wrote:
>> I think this is true.  Concurrency designed around message passing is 
>> far more scalable than concurrency involving shared state, for example, 
>> and message passing is really nothing more than a mechanism to increase 
>> modularity.  In fact, I've pretty much decided recently that concurrent 
>> programming is really slowly working towards a pure message-passing 
>> design similar to Erlang, and that library solutions in traditional 
>> imperative languages are simply attempts to extend the useful life of 
>> existing code (futures, etc).
> 
> SO how about a thread-pool based message-passing actor model in Tango :-)?

Concurrency support in Tango will definitely be expanded as time goes on :-)

>> As an aside, one interesting aspect of Erlang is that it turns code 
>> reliability on its head to a degree by simply aborting the process if an 
>> exception occurs.  This seems far preferable to the manual exception 
>> recovery typically done in C++, Java, and D, which reduces code clarity 
>> and can be difficult to get right.  Concepts like DBC, however, provide 
>> a quite useful degree of boundary checking, and seem applicable 
>> regardless of the degree of modularity introduced.
> 
> Depends what type of exception. The concept of "exception" is being used to represent both bugs/unexpected state in the code (which should be handled explicitly by the coder) and unexpected circumstances in resources. Should your web browser halt if it can't connect to a server? Should your word processor halt if it tries to save to a read-only file? These are the situations where exceptions are far clearer than C's way of dealing with error codes, etc.

It shouldn't halt, but a sub-process handling some portion of the 
web-page loading might.  Say you launch a process to grab the HTML and 
it in turn launches additional processes to get the images, etc, which 
need to be displayed.  Any one of these processes may encounter an error 
and abort, but the browser would continue to run and the rest of the 
page would still load.  The key, I think, is considering processes in 
Erlang to be a bit like classes or modules in D.  Exception recovery 
isn't done simply because the cost of starting a process is so low that 
there's no reason to bother--just spawn a new process and try again.


Sean