[erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution
Tue Jun 24 21:49:59 CEST 2014
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
> 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
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.
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
More information about the erlang-questions