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

[zxq9]

On Tuesday 24 June 2014 15:49:59 Miles Fidelman wrote:
> Loïc Hoguin wrote:
> > On 06/24/2014 01:54 PM, Peer Stritzinger wrote:
> >> But I should probably give up, the "Erlang is a implementation of the
> >> Actor model" meme seems to be stronger than unimportant details than
> >> semantics.
> > 
> > When people talk about Erlang and actors I look at them funny. Not
> > because of what you said, how Erlang isn't actors, but because that's
> > completely missing the point of Erlang.
> > 
> > The beauty of the Erlang processes is that they were made for
> > achieving fault tolerance. It is this particular aspect that make them
> > incredibly good: you can focus on the happy path, "let it crash",
> > keeping the code very tidy; you can detect failure and recover from it
> > automatically, allowing you to sleep at night; and you don't have to
> > deal with broken state.
> > 
> > For me Erlang is first fault tolerant, then concurrent, then
> > functional, yet for many people it seems to be the opposite order. I
> > personally care very little about Erlang being functional (though I do
> > care a great deal about immutability and pattern matching being the
> > default behavior, the rest not so much), and the concurrency is nice
> > but only because it enables all the fault tolerance features of the
> > language.
> 
> Interesting - because what I find most compelling is the concurrency.
> Perhaps, this is because I came to Erlang with a background in two areas
> that emphasize concurrent thinking - networking and simulation.  In the
> first, things tend to be easy - new connection, span a process for the
> duration.  For simulation, though, the paradigm is often "an object per
> simulated entity - with spaghetti coded execution pathways that run
> every second."  Erlang provides a run-time environment that's much
> better for thinking about inherently concurrent problems.

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.

Since we're hoppping down the semantic rabbit-hole in this discussion already, 
I suppose its worth mentioning that the term "fault-tolerance" in this context 
is outlined by the idea that an asynchronous message-stew requires a program 
to be capable of reasonable behavior when unexpected messages are received, 
and that this should not mandate the programmer write a special case for every 
combination that might occur along the message*state matrix. Not every 
definition of "fault-tolerance" carries this meaning.

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.

I recall a talk Ulf Wiger gave a while back about something like this. Along 
the lines of how its easy to drown in an ocean of incidental complexity in 
large concurrent systems, and "large" doesn't have to be very big. Actually, 
he gave examples in Erlang of how you can even drown in Erlang, so its not 
just language-specific, it was more a structural issue. (Now I want to go back 
and find that again...)

My point is that its hard to have concurrency without fault-tolerance, fault-
tolerance only means what we think it means in a concurrent environment, and 
both are much easier to think about in a functional, immutable world (with 
assignment meaning labels, not variable storage). So each of these three 
points is hard to assign a priority, regardless what feature we personally 
think of as most important.

-Craig