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

[Peer Stritzinger]

On 2014-06-23 11:43:11 +0000, Raphael Korsoski said:

> On the other hand, it is more or less trivial to _implement_ models of 
> Actors in Erlang, whichever of the many proposed semantics for actors 
> you choose. 

I agree, except the automatic garbage collection of actors that are 
inactive which seems so important for Hewitt.  The latter would not be 
trivial to implement.  Not sure why he thinks its such a big deal.

> Although I have never completed the exercise, I believe quite strongly 
> that you could also fully embed Erlang's style of concurrency in both 
> abstract actor models and operational (process calculi) implementations 
> of those, with relatively simple, or even trivial, translations; eg 
> selective receive as a set of actors with a receptionist.

Well in theory you can implement everything in almost everything. In 
practice its eaither infeasible or has quite bad performance if you 
model Erlangs mailbox, linking and monitoring behavour.

> In my opinion, strictly separating Erlang-style concurrency and the 
> Actor model is only of academic interest; unless you are implementing, 
> say, an Erlang runtime of course. 

I disagree.  Almost all the good things in Erlang come from differences 
from the Actor model:

* mailboxes with selective receive help to significantly reduce state 
complexity.  If you don't know what I mean please watch 
http://www.infoq.com/presentations/Death-by-Accidental-Complexity

Of cours if you are only using sycronous gen_server calls you won't 
notice the differences but at the same time giving up lots of expresive 
power.

* links and monitors and the failure handling derived from them

* The possibility of sequential long running preempted code

Generally Erlang implements something that "solves the problem", wheras 
actors are just a theoretical construct.

Cheers
-- Peer

> The differences are certainly relevant to category theorists, language 
> theorists, mathematicians working in the Curry-Howard domain and so 
> forth, but for the general programmer the differences are more or less 
> implementation details ("up-to the usual nonsense").
> 
> By contrast, although it is just as relevant, we generally don't 
> discern between object-oriented models that allow either contra- or 
> covariant inheritance (or both). Should we really distinguish 
> process-oriented models by the semantics of the "becomes" relation?
> 
> /// Raphael
> 
> 
> On Mon, Jun 23, 2014 at 4:40 AM, zxq9 <zxq9@REDACTED> wrote:
> On Monday 23 June 2014 11:22:36 Ngoc Dao wrote:
> > > In many ways an Erlang system does have an OS feeling about it. At least
> >
> > I think so.
> >
> > I think so, too:
> > http://www.slideshare.net/ngocdaothanh/cloud-erlang
> 
> I enjoyed the abbreviated cut-down (once I got over the use of the empty,
> warped, buzzsound term "cloud"... its necessary to attract attention from a
> certain type of party, but they aren't the sort who are really going to
> embrace what you have to say).  Its a good reference to explain why Erlang
> implies a lot more than just a language. Much better, I think, to do like
> you've done here and treat Erlang/OTP as a system that supports a very
> different model of computation than most folks are accustomed to than to start
> them on the language syntax first.
> 
> Actually, quite a few interesting early attempts at explaining Erlang as a
> system up-front have come out over the last few threads. Most of this stuff is
> unpolished, but represents a lot of effort in a good direction.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140623/0fd8fccf/attachment.htm>