[erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution
Tue Jun 24 22:44:48 CEST 2014
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.
More information about the erlang-questions