Advantages of a large number of threads cf other approaches?

[jonathan@REDACTED]

On 16 Feb 2004 at 19:32, Joe Armstrong wrote:
> > * Internet servers - why not use asynchronous sockets running in a 
> > single thread?
> >
> 
>   Because of errors.
> 
>   Think of the process as  not only providing units of concurrency but
> also of providing error encapsulation boundaries.
> 
>   Erlang was  designed for programming fault-tolerant systems  - to do
> so we must make sure that  faulty code running somewhere in the system
> does  not   crash  good  code   -  the  process  provides   the  error
> encapsulation boundaries.  This is  the single most important property
> that a process has.

This was pretty much what I very tentatively said. It's nice to have 
someone who's opinion eans something tell me I've not made a 
(tentative) idiot out of myself...

> > * Simulations - why use an object per thread rather than a "classic" 
> > OO approach?
> 
>   This depends  upon the  simulation - if  you are modeling  the real
> world  then mapping  each concurrent  object  in the  real world  with
> exactly one  concurrent processes bridges between the  gap between the
> model and  the simulation code in a  very natural way -  the code will
> almost "write itself".

I've heard this said before (and have read code samples etc) but I 
keep feeling I'm missing something. It's so easy to have all your 
objects inherit from a Smalltalk/C++ base class with an update method 
and loop through all of them. Possibly I'm at the stage where I'm 
over-adapted to OO and no longer notice some of the discomforts...

- Jonathan