[erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution

[zxq9]

On Tuesday 24 June 2014 17:05:21 Miles Fidelman wrote:
> zxq9 wrote:
> > I think the more important aspect here being that its very hard to be
> > happy
> > with concurrency in a world where you have to handle every combination of
> > message*state, and that means fault tolerance is a neccessary component of
> > any environment where one can happily build large concurrent systems. In
> > particular, any large system is non-trivial, and concurrency itself is
> > non- trivial. Without fault-tolerance you wind up with an explosively
> > complex fault situation to handle.
> > 
> > 
> > Come to think of it, I don't think it would be very easy to apply Erlang's
> > concept of fault-tolerance without pattern matching as a central feature
> > in
> > many areas of the language. I could be wrong, I'm just trying to imagine
> > an
> > alternative without pattern matching -- and I don't see any alternative
> > than to emulate it with exclusive guards or something (which still
> > equates to pattern-matching, just less easy to read), which in the
> > extreme case is almost as bad as the common practice in some languages of
> > actually enumerating every negative case -- which usually vastly
> > outnumber the positive cases -- and providing an exception handler for
> > each.
> 
> <snip>
> 
> Well, falling further down the rabbit hole ....
> 
> I kind of agree with you that massive concurrency and fault-tolerance go
> hand-in-hand.
> 
> On the other hand, I kind of see pattern matching as more associated
> with message-oriented communication:  Somehow I don't see doing a lot of
> message selection and processing without pattern matching at the front end.

I believe message passing is going to be a necessary part of any massively 
concurrent system (otherwise it couldn't get very massive...).

In other words, I not only agree with you, I think this is not even "on the 
other hand" -- you're identifying another part that is central to Erlang 
having done things right. Without message passing a system would, at the very 
least, require an API to emulate the act of message passing (and so what's the 
difference?). Its also interesting that this is what Schemers mean when they 
say "message passing" but not what Java-like OOP means by it (and its not 
shades of gray -- message passing is not RPC, though it may support it). 
Consider what happens with "web APIs": in a race to avoid inventing a protocol 
by using HTTP folks are constantly re-inventing protocols in a drastically 
limited semantic space (within URL-safe strings) -- an advanced form of 
missing the point while message passing.