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

[Miles Fidelman]

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.

Miles Fidelman




-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra