[erlang-questions] Go vs Erlang for distribution

[Alexei Sholik]

Hi,

Let me say from the beginning that this is not meant as a flame post. I'm genuinely interested in some issues related to Erlang's adoption and how people outside of its community see its fitness for the domain where the insiders know it shines – building distributed systems.

My questions have been prompted by the apparent appeal of Go as a suitable tool for that exact domain. I have noticed the appeal being expressed both outside and _inside_ Erlang community (will explain soon).

The reason for my asking on this particular list is twofold:

  1. After discovering Erlang (not just the language, but in the wider sense: Erlang VM, OTP, its founding principles) I see it as a great fit for building distributed systems that can survive and auto-recover from various kinds of failures. It has also been proven over the years of being used in production. Erlang experts are the kind of people to go to when looking for an advice in this area.

  2. In his recent talk at EUC Garrett Smith showed us an interesting slide[1] where Go appears to be one of the primary alternatives to Erlang, as chosen by _Erlang programmers themselves_. To me this implies that Erlang programmers have found in Go some of the principles Erlang builds upon, the fact I'm going to dispute below.

  [1]: https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large

So now comes the question: what do Erlang programmers think about Go stealing some of the mindshare (and job-share) in the area of building distributed systems? Why would if be a good option? Or not an option at all? Just professional opinions based on your experience with Erlang please.

Let me explain what suggests Go might be a viable alternative:

  * the slide mentioned above

  * Go has been used for teaching distributed systems at the Carnegie Mellon University since 2011. (Go 1 was release in early 2012) See this blog from the teacher: http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html

  * increased activity on projects such as libswarm[2], libchan[3], there are more.

  [2]: https://github.com/docker/libswarm
  [3]: https://github.com/docker/libchan

If you haven't been keeping up with Go, here's a brief overview of its principles:

  * imperative, statically typed, garbage collected, lower level than scripting languages, but higher level than C
  * builtin concurrency with lightweight processes (called goroutines) which are scheduled cooperatively

  * single address space for all goroutines (modifying shared data is discouraged, but possible); hence no isolation

  * goroutines have no identity, communication between them is only possible through channels; hence no ability to monitor or link to goroutines, so no supervision

  * writing to a channel is always synchronous; it is possible to make a buffered channel, but once the buffer is full, the next goroutine trying to write to it will block

  * all errors must be handled explicitly; can be done at goroutine level by setting up a catch-all handler. But crashing in the catch-call handler will crash the goroutine. And crashing a goroutine crashes the whole program. No Erlang-style "let it crash" or "let someone else handle errors"

From this short survey Go looks more like the ultimate antagonist to Erlang, or at least its philosophy. What could justify its being chosen as an _alternative_ to Erlang?

Sorry if it turned out a bit too long. Ultimately, I'm curious about the reasons Go appears in a huge font on Garrett's slide. Also, finding out why Go has seen a tremendous growth in just 2 years since initial stable release and is already seen as a good fit for tasks Erlang is considered the best tool in these circles might shed some light on which steps Erlang community could take to increase the awareness about its merits (especially in the light of a few recent threads on this list).

This ended up rather convoluted, I know. If it was the wrong place to bring up this topic, I apologize. Feel free to ignore this thread in that case.

Thanks for reading this far.

--
Best regards
Alexei Sholik

[zxq9]

On Sunday 22 June 2014 01:43:49 Alexei Sholik wrote:
> 2. In his recent talk at EUC Garrett Smith showed us an interesting
> slide[1] where Go appears to be one of the primary alternatives to Erlang,
> as chosen by _Erlang programmers themselves_. To me this implies that
> Erlang programmers have found in Go some of the principles Erlang builds
> upon, the fact I'm going to dispute below.

I don't see that at all. There are Python, Common Lisp, OpenCL and D
frameworks that go a lot further toward emulating a distributed machine than
anything I've seen in Go. But they are external things, just like any
framework for distributed computing in Go would be. The syntax surrounding its
use would be the responsibility of that platform/library, and not really have
any inherently Go specific about it.

> So now comes the question: what do Erlang programmers think about Go
> stealing some of the mindshare (and job-share) in the area of building
> distributed systems? Why would if be a good option? Or not an option at
> all? Just professional opinions based on your experience with Erlang please.

An inflammatory question if there ever was. ;-)

Go is not, in my opinion, as compelling as Algol 68, D, Guile, Python or even
Ada for any particular problem domain. Neither was Java. And this is where the
historical parallel resides.

Google is a huge company that is spending a *lot* of effort in an attempt to
prevent yet another of their expensive toys winding up in the rubbish bin of
digital history.

Sun went to the exactly the same effort -- to hype a language and pet VM.
Their focus on marketing (as opposed to technology) was so complete that it
successfully warped our vocabulary about "objects" to meet their product while
doing nothing to make their product advance the state of the art. That the
industry and academia largely went along with this says more about human
nature than technology.

Google, able to control a large percentage of what the majority of us see and
hear, may be capable of the same trick.

I don't see Go as offering anything new. At all. Erlang is a decent language,
but as you noted, that's not the real magic as its more an artifact of the
history of the platform's implementation than anything else. The important
thing is the platform and the complete way in which it embraces the Alan Kay
sense of "objects" (and that term being so loaded and meaningless now, has
been avoided in favor of "processes"). The Erlang platform is better because
it requires that I do less work to get that sort of functionality. It emulates
a distributed machine in a world where the hardware market has been pushed
toward One Arch to Rule Them All.

And that means that Go is yet another Algol descendant that I would be forced
to learn for very little gain. Go doesn't have anything new to teach me about
problem decomposition, expression of my intuitions about process, or
formalization of either. Erlang's platform, on the other hand, enables a
radically different way of thinking about these things. This is probably the
most important thing I can say about a language or platform.

This is an older, but quite interesting, article:
http://cowlark.com/2009-11-15-go/

Anyway, I hope people who find Go a comfortable sytnax to write their Algol
programs in use it to great effect. I'll adapt to that whenever I wind up
working on something I care about that is already written in Go -- just like I
have with Ruby, C++, D, Perl, etc. Placing too much emphasis on the difference
is, in my opinion, a waste of effort -- because it doesn't help me get work
done.
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Garry Hodgson]

for me personally, i don’t see Go as an alternative to erlang,
or python, or any of the higher level languages i've become
accustomed to. but i do see it as a potential alternative to C
for cases where i need to do low level, performance critical
stuff.

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

-- 
Garry Hodgson
AT&T Chief Security Office (CSO)

"This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited."

[Felix Gallo]

For the average developer I see day-to-day coming from C or python or java or node, Go seems to tick many of the boxes: clean, immediately graspable, new, well-marketed, comes from famous unix people famous for good unix things, fast(er) for many use cases, and is said to handle that brand new 'concurrency' problem that everyone's started to talk about and put on their resumes.

Erlang and Go don't really play in the same space, in my opinion, so I'm not all that worried that Erlang is going to vanish under a wave of Go.  Go's foibles around error handling, ecosystem, and tooling, and a roll-your-own channel model, will tend to mean Go's sweet spot is small tools that stay small; but it's solid in that area owing to the slightly more modern type system and safety features.  Erlang's foibles around skill curve, ecosystem complexity, and gaining the ability to reason effectively means it's not great for the small, but kicks ass in the huge where the OTP and actor tax are offset by the radical advantages they convey in the ability to debug and reason about behavior.

Maybe one day a better, more comprehensible functional language and ecosystem revolving around the actor model comes out and Erlang fades.  Could be Valim.  Way more likely Valim than Pike.

F.

[Miles Fidelman]

One quibble - see below:

zxq9 wrote:
> On Sunday 22 June 2014 01:43:49 Alexei Sholik wrote:
>> 2. In his recent talk at EUC Garrett Smith showed us an interesting
>> slide[1] where Go appears to be one of the primary alternatives to Erlang,
>> as chosen by _Erlang programmers themselves_. To me this implies that
>> Erlang programmers have found in Go some of the principles Erlang builds
>> upon, the fact I'm going to dispute below.

<snip>

>
> I don't see Go as offering anything new. At all. Erlang is a decent language,
> but as you noted, that's not the real magic as its more an artifact of the
> history of the platform's implementation than anything else. The important
> thing is the platform and the complete way in which it embraces the Alan Kay
> sense of "objects" (and that term being so loaded and meaningless now, has
> been avoided in favor of "processes").

I see Erlang as an implementation of the Actor model, a la Carl Hewitt -
which developed in parallel with Alan Kay's work, and influenced it (and
both were influenced by Simula). Smalltalk-72 included message-passing
concurrency of sorts, but that pretty much went away in later versions
of Smalltalk (messages remained, but multiple threads of execution kind
of went away).

There's a very interesting discussion of this in the archives of the
fonc email list - starting at
http://vpri.org/mailman/private/fonc/2013/003975.html (which builds on
Alan's "Early History of Smalltalk" paper -
http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html).

Miles Fidelman


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

[zxq9]

Unfortunately the fonc list archive at vpri is behind a password wall, so I'll
just have to accept ignorance of the discussion.

The other link, however, is open and skimming through it, an excellent
organization of many of the points I've heard Alan Kay and a few other folks
make throughout the years. The chronological arrangement of the essay,
however, makes the ideas into a story -- an exciting one to my inner nerd.

Thanks for the references.

One thing I enjoy about the archives of this list are the frequency and
quality of external references. Quite regularly a reference tossed out in a
peripheral discussion such as this one leads me to a new way of thinking about
a core concept that is useful in Erlang (it helps that a lot of the otherwise
esoteric stuff is quite trivial and well documented on this platform).

-Craig

[Garrett Smith]

On Sat, Jun 21, 2014 at 5:43 PM, Alexei Sholik <alcos...@gmail.com> wrote:
> Hi,

-snip-

> 2. In his recent talk at EUC Garrett Smith showed us an interesting
> slide[1] where Go appears to be one of the primary alternatives to Erlang,
> as chosen by _Erlang programmers themselves_. To me this implies that Erlang
> programmers have found in Go some of the principles Erlang builds upon, the
> fact I'm going to dispute below.
>
> [1]: https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large
>
> So now comes the question: what do Erlang programmers think about Go
> stealing some of the mindshare (and job-share) in the area of building
> distributed systems? Why would if be a good option? Or not an option at all?
> Just professional opinions based on your experience with Erlang please.

The question that people answered was:

What languages or frameworks would you consider as alternatives
to Erlang?

This seems straight forward enough, but each answer was in
narrative/text format, so there was usually some context. Often
"alternative" was interpreted to mean something closer to
"complement".

Users of Erlang and Go are generally well aware of the extreme
differences as a language and platform.

Go is thought of as a more OS/posix friendly language that offers some
concurrency features. So it's an alternative in cases where
performance and systems programming/integration is important. It's not
a drop-in replacement for Erlang, of course.

Respondents frequently cited golang.org as a motivation for adoption,
or at least their comfort level. It seems there's some inspiration
there in the way Go is marketed/communicated.

My personal takeaway is that the Erlang community and Ericsson might
look closely at the way Google presents and supports Go. I have no
idea what specifically would come from this, but I plan on spending
some time on this in the near future.

So, one last observation. Let's be careful not to over read this
survey. It's provocative, fine. But my hope was that we could measure
a little and then do a little, then rinse and repeat. And indeed there
are a number of practical steps that people are talking about that
have emerged from this work. But let's be aware that, for some, these
topics can serve as emotional and cathartic outlets with little chance
of improving Erlang or its adoption. I'm not suggesting this is
happening - just that it might. Because then people will start yelling
at me off list for stirring all this up. Seriously, I can sense them
leering from the shadows.

Garrett

[Tristan Sloughter]

I wrote a post about this recently because I found the idea of Go being an alternative to be ludicrous, especially after working with Go: http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/

 

--

Tristan Sloughter

tristan....@gmail.com

 

[Peer Stritzinger]

On 2014-06-22 02:07:12 +0000, Miles Fidelman said:
> I see Erlang as an implementation of the Actor model, a la Carl Hewitt -

This crops up again and again but still isn't true.

Erlang does *not* implement Actors but processes with links/monitors
mailboxes and messages, which are not equivalent to actors.

Processes: sequence of function calls interspresed with (selective)
receives that pick out someting out of the mailbox.

Actor: has to handle every message immediately, the actions a message
triggers are happening concurrently, nothing longer running or
sequential allowed.

Hewitt says himself that Erlang does not implement Actors:
http://arxiv.org/pdf/1008.1459.pdf

He picks on different things like "silent process failure" instead of
exceptions (which don't make much sense for somone familiar with
Erlang) and that Actors seem to be garbage collected if they are
"unneded" probably no longer referenced from the outside and Erlang
needs "internal termination".

Hewitt writes mostly what he finds lacking but on the other hand I find
the process with mailbox, selective receive and links/monitors (not ver
silent ;-) more powerful that simple Actors.

Also as aside from what I've heard Erlangs creators didn't look at
Actors when creating.

Cheers,
-- Peer

[Robert Virding]

We had never heard of the actor model, at least I hadn't. We had other inputs, amongst others Eripascal which an internal Ericsson version of Pascal which had processes and messages.

Hewitt got a lot of things wrong in his description of Erlang.

Robert

[Robert Virding]

And of course OSes which embody a lot of the ideas we were after, but in such a way that they were/are way to heavy for what we were after. In many ways an Erlang system does have an OS feeling about it. At least I think so.

Robert

[Ngoc Dao]

> 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

[zxq9]

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.

[Raphael Korsoski]

My €.2, as a computer scientist (categories for the win) and an Erlang coder:

There are certainly formal differences between Erlang-style concurrency and the many different Actor Models that have appeared in the literature (cf. Aπ-calculus). The runtime doesn't use a reduced set of communication primitives as a foundational concept, such as in the pi-calculus formulations of Actor Models. I haven't seen any proof of the fairness/progress property for Erlang, either.

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. 

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.

I'd go so far as to say that Erlang and the Actor Model are in the same programming paradigm, but with different axioms in their semantics-- although that's of course conjecture without (large, tedious) proof....

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. 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

[Ignas Vyšniauskas]

On Mon, Jun 23, 2014 at 2:43 PM, Raphael Korsoski <psid...@gmail.com> wrote:
> I'd go so far as to say that Erlang and the Actor Model are in the same
> programming paradigm, but with different axioms in their semantics--
> although that's of course conjecture without (large, tedious) proof....
>
> 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. 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").

I agree with you in the general spirit of "formally it doesn't matter
much because it's mostly the same thing."

However, there is one crucial thing in Erlang which, on the positive
side makes it a very practical tool, and on the negative side makes it
very hard to talk about formal semantics and prove things like
progress. This is the availability of the `receiver .. after ..`
primitive. Allowing local-timing-based behaviour in processes usually
means that you need some very strong global fairness assumptions in
order to do any kind of formal proofs. I don't see how one could
obtain a (useful) representation of Erlang semantics in any of the
usual process calculi without ignoring this fact. It would be
interesting to find out if anyone ever did something similar formally.

--
Ignas

[Alexei Sholik]

Thank you all for the answers!

I personally agree that Go would be most suitable as a complement to Erlang, not as a primary tool for building reliable systems. However, that goes in disagreement to Go authors which have claimed its design to be tailored to building large-scale projects.

One little nitpick I have is about zxq9's first reply which mentions:

Google is a huge company that is spending a *lot* of effort in an attempt to
prevent yet another of their expensive toys winding up in the rubbish bin of
digital history.

I have been following the Go community (not too closely) since 2012 and I haven't seen any indications of Google pouring monetary or marketing resources into promoting Go. Obviously, it has been paying salaries to the core team (of some ~5-8 members), but apart from that, unless it is also paying blog authors and companies to adopt Go, it is fair to say that most of the praise Go is continuously receiving comes from the word-of-mouth and talks given by its authors.

TL;DR: there is no massive campaign carried out by Google to promote Go like Sun did with Java or MS with C#. This is already offtopic, but I feel I had to point that out.

Getting back on Erlang track, I'd like to thank you all again for the answers. My curiosity has been satisfied, so I'm not going to trouble you with any more Go-related discussions.

Cheers!
Alex

_______________________________________________

erlang-questions mailing list

erlang-q...@erlang.org

http://erlang.org/mailman/listinfo/erlang-questions

[Garrett Smith]

On Sun, Jun 22, 2014 at 4:02 PM, Tristan Sloughter
<tristan....@gmail.com> wrote:
> I wrote a post about this recently because I found the idea of Go being an
> alternative to be ludicrous, especially after working with Go:
> http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/

This is a very good article that capably dives into the differences
between Go and Erlang. If you haven't read it and care about any of
this, read it :)

Garrett

[Raphael Korsoski]

The only dissertation on the subject that I'm aware of is Lars Åke Fredlund's thesis from 2001: "A Framework for Reasoning about ERLANG Code"

It uses modal logic to model time; specifically an extension of the mu-calculus in the "usual" Gentzen-style deductive framework.

If there are other approaches that have been investigated for Erlang specifically, I'd be very interested in links etc!

/// Raphael

[zxq9]

On Monday 23 June 2014 16:34:15 Alexei Sholik wrote:

> One little nitpick I have is about zxq9's first reply which mentions:
>
> Google is a huge company that is spending a *lot* of effort in an attempt to
> > prevent yet another of their expensive toys winding up in the rubbish bin
> > of
> > digital history.
>
> I have been following the Go community (not too closely) since 2012 and I
> haven't seen any indications of Google pouring monetary or marketing
> resources into promoting Go. Obviously, it has been paying salaries to the
> core team (of some ~5-8 members), but apart from that, unless it is also
> paying blog authors and companies to adopt Go, it is fair to say that most
> of the praise Go is continuously receiving comes from the word-of-mouth and
> talks given by its authors.
>
> TL;DR: there is no massive campaign carried out by Google to promote Go
> like Sun did with Java or MS with C#. This is already offtopic, but I feel
> I had to point that out.

I'd like to point out that Google doesn't have to carry out a massive
campaign; they control your search results.

I just opened a sterile environment each in Japan, one in the US and one in
France to test this out. A search for "Go" on any Google property points me to
Go language resources -- videos, tutorials, conference notes, blogs, etc. --
pages of them, before anything else in most cases and most variants of the
search (even when I'm trying to be specific that I want the verb, like "go
definition").

The same search on ixquick, Bing, Goo, and DuckDuckGo turn up links to
Disney's online property (go.com), the traditional game of Go on Wikipedia, a
Japanese pop group, verb definitions on two dictionaries, some ESPN sports
page, a 1999 movie called "Go" and any number of other things, but Go the
language is nowhere to be found.

And you're telling me there isn't an absolutely massive publicity campaign
going on? Just because Google is in a unique position to make this both cost
almost nothing and require almost no effort doesn't mean the effort isn't
significant and targetted.

-Craig

[Yann SECQ]

Le 23/06/2014 16:37, Raphael Korsoski a écrit :
> The only dissertation on the subject that I'm aware of is Lars Åke
> Fredlund's thesis from 2001: "A Framework for Reasoning about ERLANG Code"
>
> It uses modal logic to model time; specifically an extension of the
> mu-calculus in the "usual" Gentzen-style deductive framework.
>
> If there are other approaches that have been investigated for Erlang
> specifically, I'd be very interested in links etc!

Perhaps this one:
*Formally based tool support for model checking Erlang applications*
Qiang Guo, John Derrick
International Journal on Software Tools for Technology Transfer
August 2011, Volume 13, Issue 4, pp 355-376

http://link.springer.com/article/10.1007%2Fs10009-010-0179-1

Best regards, yann.

--
Contact: yann.secq{at}univ-lille1.fr | www.lifl.fr/~secq
www.ouverture-independance.fr | www.sauvonsluniversite.com
--
"Ne désespérez jamais. Faites infuser davantage.", Henri Michaux

[Ulf Wiger]

I have argued in a number of presentations that what selective receive does for Erlang is to allow a form of ‘local-scoping’ of events. Haskell, Occam and for that matter, UNIX select(), accomplish this using separate buffered (or blocking) channels, where the program can choose which channel(s) to receive from at any given time.

The underlying observation is that there is no defined ordering between events which arrive to a process from different senders. What any selective receive model does is to allow the receiver to reduce the statespace by ignoring events that are irrelevant for the operation at hand.

I’m not sure who deserves most credit for talking about ‘accidental complexity’ in terms of Erlang programming, but I’m leaning towards crediting Joe for evangelizing it the most, although I’ve seen stencils from the late ‘70s where Mike Williams wrote very good stuff about it. The term has of course been used elsewhere, not least by Fred Brooks.

One can compare FIFO, run-to-completion message handling with GOTO programming, and I recall Simon Peyton-Jones noting that the key to avoiding the problem is to have proper scoping of messages (c.f. variable scoping).

Reducing the state space is of course key to any formal verification effort, so I’d claim that Erlang actually provides some tools for extending the reach of formal verification. But the real benefit of Erlang is that it allows developers to write more complex event handling systems that are at least *debuggable*, if not entirely formally verifiable.

The properties ‘fairness’ and ‘reachability’ are global, and are made a bit more difficult to verify in systems that make use of selective receive. OTOH, verification of a global state-event matrix has a pretty low complexity ceiling, and at least in telecoms (and, I’d claim, in the Web), a missed deadline is not a system-wide failure, which means that you can get very far with informal testing and statistical goodness properties.’

BR,
Ulf W

On 23 Jun 2014, at 14:17, Ignas Vyšniauskas <i.vysn...@gmail.com> wrote:

> This is the availability of the `receiver .. after ..`
> primitive. Allowing local-timing-based behaviour in processes usually
> means that you need some very strong global fairness assumptions in
> order to do any kind of formal proofs. I don't see how one could
> obtain a (useful) representation of Erlang semantics in any of the
> usual process calculi without ignoring this fact.

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com

[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

[Raoul Duke]

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

well yes the Actor model stuff was/is intended to be a foundational
thing to build on top of. so when you say "theoretical construct" in a
way it would be taken as a compliment, not an insult ;-)

so i expect from Hewlitt et. al.'s perspective one would want to
implement Erlang on top of actors. :-)

[Miles Fidelman]

Raoul Duke wrote:
>> Generally Erlang implements something that "solves the problem", wheras
>> actors are just a theoretical construct.
> well yes the Actor model stuff was/is intended to be a foundational
> thing to build on top of. so when you say "theoretical construct" in a
> way it would be taken as a compliment, not an insult ;-)
>
> so i expect from Hewlitt et. al.'s perspective one would want to
> implement Erlang on top of actors. :-)
> _______________________________________________
>

Seems to me that the core of the actor model is shared-nothing, message
passing concurrency. Yes there are some fine differences between the
full model as defined by Hewitt (and implemented by him in some cases)
and Erlang - but that seems to get into the world of implementation details.

Now whether any of that influenced Erlang, or was a case of parallel
invention, is a different question.

Miles Fidelman


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

[Peer Stritzinger]

On 2014-06-23 22:14:28 +0000, Miles Fidelman said:

> Raoul Duke wrote:
>>> Generally Erlang implements something that "solves the problem", wheras
>>> actors are just a theoretical construct.
>> well yes the Actor model stuff was/is intended to be a foundational
>> thing to build on top of. so when you say "theoretical construct" in a
>> way it would be taken as a compliment, not an insult ;-)
>>
>> so i expect from Hewlitt et. al.'s perspective one would want to
>> implement Erlang on top of actors. :-)
>> _______________________________________________
>>
>
> Seems to me that the core of the actor model is shared-nothing, message
> passing concurrency. Yes there are some fine differences between the
> full model as defined by Hewitt (and implemented by him in some cases)
> and Erlang - but that seems to get into the world of implementation details.

How is having a quite different semantics being a "implementation detail".

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.

Peer

[Yann SECQ]

Le 24/06/2014 13:54, Peer Stritzinger a écrit :
> How is having a quite different semantics being a "implementation detail".
> 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.

I've found this piece particularly interesting in the context
of this thread:

The Hewitt Actor Model and the Labyrinth of Metaphysics
http://carlos-trigoso.com/2014/03/07/out-of-the-labyrinth-of-metaphysics-v-001/

Cheers, yann.

--
Contact: yann.secq{at}univ-lille1.fr | www.lifl.fr/~secq
www.ouverture-independance.fr | www.sauvonsluniversite.com
--
"Ne désespérez jamais. Faites infuser davantage.", Henri Michaux

[Michalis Kargakis]

When searching for "go" in DuckDuckGo, which search engine i primarily use,
i always get golang.org and their google code repository in the top-10 results.
(Note that i don't keep any browsing history, cookies etc. etc. on my Firefox)
And by using the same logic you use, why should Microsoft's Bing point to a
programming language created by a competitor?

On a different note most programming languages (eg. Java, Erlang, Scala etc.)
have searchable enough names. Why shouldn't Go be on the same level?
Even if Google indeed are tweaking their results in favor of Go i can't see
where does it have an advantage over other programming languages. This 
whole argument is laughable at the very least.

I will agree with alco about Google not marketing Go. I am closely following
the Go community and its ecosystem since late 2012 and i have never seen
such a thing. Instead the language has exploded because of its many success
stories (see Docker, Soundcloud, CloudFlare and many others). Even Apple
has started hiring Go developers.

Many whine that Go doesn't bring anything new to the table but that's totally
not the point. If you want to know more about why Go is considered to be a
decent language with great potential just search for any of the aforementioned
companies, watch any video off GopherCon, etc. and try not to cite blogposts
from the era when Go still used semicolons. :)

Sorry for the off-topic answer.

[Miles Fidelman]

Peer Stritzinger wrote:
> On 2014-06-23 22:14:28 +0000, Miles Fidelman said:
>
>> Raoul Duke wrote:
>>>> Generally Erlang implements something that "solves the problem",
>>>> wheras
>>>> actors are just a theoretical construct.
>>> well yes the Actor model stuff was/is intended to be a foundational
>>> thing to build on top of. so when you say "theoretical construct" in a
>>> way it would be taken as a compliment, not an insult ;-)
>>>
>>> so i expect from Hewlitt et. al.'s perspective one would want to
>>> implement Erlang on top of actors. :-)
>>> _______________________________________________
>>>
>>
>> Seems to me that the core of the actor model is shared-nothing, message
>> passing concurrency. Yes there are some fine differences between the
>> full model as defined by Hewitt (and implemented by him in some cases)
>> and Erlang - but that seems to get into the world of implementation
>> details.
>
> How is having a quite different semantics being a "implementation
> detail".
>
> 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.
>

Maybe this is a clearer way of looking at it: (?)

1. From a 50,000 foot level, the Actor Model is a model of computation
characterized by actors, messages, and message-passing concurrency.
2. The Actor Model presents a useful way to conceptualize certain
classes of problems
3. Erlang is arguably the best, most mature programming/run-time
environment for implementing systems that fit Actor-oriented design patterns

Beyond that:
4. The Actor Model, as formally defined by Hewitt (including some
mathematical modeling thereof), differs from Erlang in some ways (or
Erlang differs from it). Though, as Hewitt says, "As was the case with
the lambda calculus and functional programming, it has taken decades
since they were invented [Hewitt, Bishop, and Steiger 1973] to
understand the scientific and engineering of Actor Systems and it is
still very much a work in progress."
5. Erlang does not appear to have been directly influenced by work on
the Actor Model. Rather, it seems to have been a case of parallel
developing of a similar approach to computation.

FYI: As a result of this thread, I've found two very educational
sources on these matters:

http://arxiv.org/ftp/arxiv/papers/1008/1008.1459.pdf (recent paper by
Hewitt, cited earlier by someone else on this thread - includes a
discussion of Erlang)

http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask
- 48 minute video of an informal discussion of the Actor Model, between
Hewitt and a couple of other academics, at the Lang.Next 2012 conference.

Cheers,

Miles Fidelman



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

[Loïc Hoguin]

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.

--
Loïc Hoguin
http://ninenines.eu

[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

_______________________________________________

[zxq9]

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

[Miles Fidelman]

zxq9 wrote:

> 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.
>
>

> 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.

<snip>

Well, falling further down the rabbit hole ....

I kind of agree with you that massive concurrency and fault-tolerance go
hand-in-hand.

On the other hand, I kind of see pattern matching as more associated
with message-oriented communication: Somehow I don't see doing a lot of
message selection and processing without pattern matching at the front end.

Cheers,

Miles

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

[Robert Virding]

I think it is very lucky that we weren't interested in, or worried about, the theoretical aspects, or that we had heard about the actor model. If we had we would probably still be discussing whether we were doing the actor model and which parts of it, or where we differed and how important that was? Or should we differ and maybe we should drop the differences to we would comply, etc ... :-)

We were trying to solve *THE* problem and this was the best solution we could come with. It was purely pragmatic. We definitely took ideas from other inputs but not from the Actor model.

Robert

[Greg Young]

I tend to search golang as a keyword when looking for things about go

As example https://www.google.com/search?q=golang+actors

--
Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when posting.
---
You received this message because you are subscribed to the Google Groups "Erlang Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to erlang-programm...@googlegroups.com.
To post to this group, send email to erlang-pr...@googlegroups.com.
Visit this group at http://groups.google.com/group/erlang-programming.
For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test

[Angel Java Lopez]

I use the trick: golang, or go google combination

[zxq9]

I believe message passing is going to be a necessary part of any massively
concurrent system (otherwise it couldn't get very massive...).

In other words, I not only agree with you, I think this is not even "on the
other hand" -- you're identifying another part that is central to Erlang
having done things right. Without message passing a system would, at the very
least, require an API to emulate the act of message passing (and so what's the
difference?). Its also interesting that this is what Schemers mean when they
say "message passing" but not what Java-like OOP means by it (and its not
shades of gray -- message passing is not RPC, though it may support it).
Consider what happens with "web APIs": in a race to avoid inventing a protocol
by using HTTP folks are constantly re-inventing protocols in a drastically
limited semantic space (within URL-safe strings) -- an advanced form of
missing the point while message passing.

[zxq9]

On Wednesday 25 June 2014 00:09:35 Robert Virding wrote:
> I think it is very lucky that we weren't interested in, or worried about,
> the theoretical aspects, or that we had heard about the actor model. If we
> had we would probably still be discussing whether we were doing the actor
> model and which parts of it, or where we differed and how important that
> was? Or should we differ and maybe we should drop the differences to we
> would comply, etc ... :-)
>
> We were trying to solve *THE* problem and this was the best solution we
> could come with. It was purely pragmatic. We definitely took ideas from
> other inputs but not from the Actor model.

Its an illustrative lesson in how to avoid slaving away at the Ivory Tower
only to have a Turing tarpit to show for it.

[Miles Fidelman]

> On Wednesday 25 June 2014 00:09:35 Robert Virding wrote:
>> I think it is very lucky that we weren't interested in, or worried about,
>> the theoretical aspects, or that we had heard about the actor model. If we
>> had we would probably still be discussing whether we were doing the actor
>> model and which parts of it, or where we differed and how important that
>> was? Or should we differ and maybe we should drop the differences to we
>> would comply, etc ... :-)
>>
>> We were trying to solve *THE* problem and this was the best solution we
>> could come with. It was purely pragmatic. We definitely took ideas from
>> other inputs but not from the Actor model.
>

Robert, I know it's probably documented somewhere, but...
1. what do (did) you see as "*THE* problem" you were trying to solve at
the time
2. what sources DID you draw from (other than the predecessor languages
at Ericsson), are there any that you'd consider primary influences?

Thanks!

Miles



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

[John Haugeland]

2. In his recent talk at EUC Garrett Smith showed us an interesting slide[1] where Go appears to be one of the primary alternatives to Erlang, as chosen by _Erlang programmers themselves_. To me this implies that Erlang programmers have found in Go some of the principles Erlang builds upon, the fact I'm going to dispute below.

The people switching from Erlang to Go weren't Erlang programmers.  They were multi-language programmers who heard about Erlang from news sites and social media, and were dabbling.  This is like thinking that Ruby is over because, for around a year, HN told them to switch to Twisted Python, or Go, or now Rust.

Nope.  People come and people Go.  We had a brief wave of dilettantes from the WhatsApp sale.  G'bye.

Dart isn't going to kill anything either.  It's a bunch of people "ooh" ing and "aah" ing at the Google name and some benchmarks that first show Go being faster than everything, and then later show Go catching up to and passing the things they previously claimed to be faster than.  (And still aren't as fast as.)

If it's a fun language, try it.  We're in no danger though.



 

[Joe Armstrong]

On Wed, Jun 25, 2014 at 5:20 PM, Miles Fidelman <mfid...@meetinghouse.net> wrote:

On Wednesday 25 June 2014 00:09:35 Robert Virding wrote:

I think it is very lucky that we weren't interested in, or worried about,
the theoretical aspects, or that we had heard about the actor model. If we
had we would probably still be discussing whether we were doing the actor
model and which parts of it, or where we differed and how important that
was? Or should we differ and maybe we should drop the differences to we
would comply, etc ... :-)

We were trying to solve *THE* problem and this was the best solution we
could come with. It was purely pragmatic. We definitely took ideas from
other inputs but not from the Actor model.

Robert, I know it's probably documented somewhere, but...
1. what do (did) you see as "*THE* problem" you were trying to solve at the time

Joe here - I'll dive in with a reply:

Bjarne Däckers thesis has a good outline of the problem the thesis is

here http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.88.1957

This blog has a good summary of Bjarnes thesis

http://jlouisramblings.blogspot.se/2012/10/ramblings-on-thesis-of-bjarne-dacker.html

 

2. what sources DID you draw from (other than the predecessor languages at Ericsson), are there any that you'd consider primary influences?

Prolog and Smalltalk in equal measure. Pattern matching and syntax was inspired by Prolog. Messaging from Smalltalk. We took a few ideas on guarded commands from

Dijkstra.

The message queues were largely inspired by SDL and occam (SDL has a graphic notation very similar to selective receive)

Links were invented by Mike Williams and based on the idea of a C-wire (a form of electrical circuit breaker).

Cheers

/Joe

[Miles Fidelman]

Joe, Thanks for the info. A bit of follow-up if I might (embedded inline):

Thanks for the pointers - and yes, the blog post is a very nice summary!

Re.

> 2. what sources DID you draw from (other than the predecessor
> languages at Ericsson), are there any that you'd consider primary
> influences?
>
>
> Prolog and Smalltalk in equal measure. Pattern matching and syntax was
> inspired by Prolog. Messaging from Smalltalk. We took a few ideas on
> guarded commands from
> Dijkstra.
>

This is mostly in the form of historical curiosity of course, but...
can you say a bit more about the Smalltalk influence, and in particular,
which version of Smalltalk? I ask, because:
- The earlier versions of smalltalk included (at least in theory) a lot
of concurrency (objects seemed a bit more like actors), whereas later
versions, starting with Smalltalk-72, pretty much dropped concurrency as
a focus (there was really interesting exchange with Alan Kay on this, a
while back, on the fonc email list).
- During that time period (very early 70s), there was a lot of
cross-fertilization between Alan Kay (Smalltalk), Hewitt (PLANNER, actor
model), and Steele and Sussman (Scheme)
(I'm kind of exploring Robert's statement that "I think it is very lucky

that we weren't interested in, or worried about, the theoretical

aspects, or that we had heard about the actor model." Particularly, in
that Alan Kay cites PLANNER as a key influence on Smalltalk. I'm kind
of interested in the origins and history of languages that treat
processes as fundamental units of computation, vs. the object model).

Thanks,

Miles Fidelman

[Gleb Peregud]

In my opinion Go is not a right tool for almost any job. It falls
short in many areas:
- it ignores two decades of programming languages design research
- it does very poorly compared to other strongly typed statically
compiled language
- it has inconsistent type system
- it is absurdly verbose
- it's error handling is horrendous
- it is not a simple nor a small language
- it has too many special cases and exceptions in it's semantics
- no polymorphic data types (not to mention higher kinded polymorphism)
- etc.

In my opinion, in almost all uses of Go I heard, I am pretty sure
choosing either Erlang or Haskell would work much better.

With all engineering hours which were invested in Go, world could have
gotten a superb language instead of something so very mediocre.

[Joe Armstrong]

I can't be sure but at a guess smalltalk-80. The version I used was

on a sun workstation and I used to take a coffee break when it garbage collected. To be honest I was more influenced by the books than the

implementation which was very slow - the red green and blue books

were great reading.

 

- During that time period (very early 70s), there was a lot of cross-fertilization between Alan Kay (Smalltalk), Hewitt (PLANNER, actor model), and Steele and Sussman (Scheme) 

(I'm kind of exploring Robert's statement that "I think it is very lucky that we weren't interested in, or worried about, the theoretical aspects, or that we had heard about the actor model." Particularly, in that Alan Kay cites PLANNER as a key influence on Smalltalk.  I'm kind of interested in the origins and history of languages that treat processes as fundamental units of computation, vs. the object model).

All the smalltalk stuff did talk about "sending messages to objects" - so was

in a sense a message passing model - there were a few problems with

this - message passing was really just a disguised function call, and time and errors didn't fit into the model.

I always thought it was funny to say "everything is an object" - time and

errors don't seem to naturally fit into this ontology - a time value (like

10.45 pm on 12 march 1984) might be represented by an object - but

not time as being something which passes as processes execute - this is some kind of invisible stuff that is outside the computation.

It's funny that the "sending message to an object" way of describing

Java and Smalltalk, Objective-C, C++ etc. objects has persisted despite the fact that this is manifestly *not* what happens (which is a function call).

In Erlang we really do send a message to an object (well a process actually) - so Erlang is probably the only OO language there is :-)

/Joe

[Raoul Duke]

Objective-C comes a hair closer than Java/C#/etc. in that the messages
are interceptable and reroutable in various ways. Yes it is still a
synchronous call stack, so no it isn't like full-on message passing,
but it isn't exactly as impoverished as the others. :-}

[Robert Raschke]

On Jun 25, 2014 7:39 PM, "Joe Armstrong" <erl...@gmail.com> wrote:
>
> I can't be sure but at a guess smalltalk-80. The version I used was
> on a sun workstation and I used to take a coffee break when it garbage collected. To be honest I was more influenced by the books than the
> implementation which was very slow - the red green and blue books
> were great reading.
>  

BTW, these three amazing books are available here: http://stephane.ducasse.free.fr/FreeBooks.html

Robby

[Miles Fidelman]

Joe Armstrong wrote:
> I can't be sure but at a guess smalltalk-80. The version I used was
> on a sun workstation and I used to take a coffee break when it garbage
> collected.

Ok, well after concurrency was out of the picture.

> To be honest I was more influenced by the books than the
> implementation which was very slow - the red green and blue books
> were great reading.

Ain't that the truth. Talk about books with long-term influence. Along
with the Smalltalk issue of Byte, and Ted Nelson's Dream Machines. :-)

> - During that time period (very early 70s), there was a lot of
> cross-fertilization between Alan Kay (Smalltalk), Hewitt (PLANNER,
> actor model), and Steele and Sussman (Scheme)
>
> (I'm kind of exploring Robert's statement that "I think it is very
> lucky that we weren't interested in, or worried about, the
> theoretical aspects, or that we had heard about the actor model."
> Particularly, in that Alan Kay cites PLANNER as a key influence on
> Smalltalk. I'm kind of interested in the origins and history of
> languages that treat processes as fundamental units of
> computation, vs. the object model).
>
>
> All the smalltalk stuff did talk about "sending messages to objects" -
> so was
> in a sense a message passing model - there were a few problems with
> this - message passing was really just a disguised function call, and
> time and errors didn't fit into the model.

Exactly. What a disappointment that turned out to me when one actually
started to play with it.

> In Erlang we really do send a message to an object (well a process
> actually) - so Erlang is probably the only OO language there is :-)
>

I periodically think about what it would look like, and work like, to
combine Erlang's core constructs and plumbing (which I continue to think
of as actors) with a Smalltalk like environment (inspectors, browsers,
classes).

Cheers,

Miles

[Richard A. O'Keefe]

I've been reading the ActoScript paper, and am quite confused.
The title of the paper is
ActorScript(TM)
extension of C#, Java, Objective C, JavaScript,
and System Verilog
using
iAdaptive(TM) concurrency
for
antiCloud(TM) privacy and security

So the title says it's an extension of several other languages
(one of which is notorious for not having any concurrency).
But then what the paper describes is variant of the actor
language from long long ago making use of quirky Unicode
characters, talking about an ActorScript-specific IDE, and
making strong claims of efficiency. The Tutorial
http://arxiv.org/pdf/1008.2748v20.pdf uses slightly different
syntax.

So what _is_ it? Is there such a thing as an ActorScript
implementation I could download or buy? ActorScript,
iAdaptive, and so on seem to be products or services of
a company called UltraConcurrent, Inc, which has apparently
applied to trademark the name WHACK-A-MOLE. It's remarkably
hard to find anything useful about them; there are a couple
of GoogleDocs that are technically in the trash. The link
for ActorScript there is to actorscript.co, which does not
exist, nor does actorscript.com. There's a link for iadaptive.co,
which doesn't exist, while iadaptive.com is blocked here on the
grounds that it contains pornography.

http://carlhewitt.info has lots of links to papers &c but
I am still searching in vain for the *expected* evidence
that ActorScript is something other than vapourware.

I say *expected* because the Actor model has been around for
a long time, Hewitt is a highly respected researcher, and I
trust him not to talk about ActorScript as an existing thing
if it isn't. But I'd certainly like to see some non-trivial
examples of code and some performance measurements to back up
claims like "ActorScript programs are as efficient as the same
implementation in machine code. For example, message passing
has essentially the same overhead as procedure calls and looping."
Surely there must be *some* measurements somewhere to back this
up, but I have spent several hours looking.

I guess I'm just going to have to keep on using Erlang...

I sometimes think that the most innovative idea in Erlang
is links. Oh, the way a downstream crash in a Unix
pipeline can take out earlier members of the pipe is
sort of similar. I wonder if that could have been one
of the inspirations for the idea?

ActorScript has "Swiss cheese" (which seems to be not entirely
unlike monitors, to the very limited extent that I understand
it), but not (again, ttvletiui) links.

[Miles Fidelman]

Richard A. O'Keefe wrote:
> I've been reading the ActoScript paper, and am quite confused.
> The title of the paper is
> ActorScript(TM)
> extension of C#, Java, Objective C, JavaScript,
> and System Verilog
> using
> iAdaptive(TM) concurrency
> for
> antiCloud(TM) privacy and security
>
> So the title says it's an extension of several other languages
> (one of which is notorious for not having any concurrency).
> But then what the paper describes is variant of the actor
> language from long long ago making use of quirky Unicode
> characters, talking about an ActorScript-specific IDE, and
> making strong claims of efficiency. The Tutorial
> http://arxiv.org/pdf/1008.2748v20.pdf uses slightly different
> syntax.
>
> So what _is_ it? Is there such a thing as an ActorScript
> implementation I could download or buy? ActorScript,
>

Probably better addressed to Carl Hewitt :-)

For what it's worth - after PLANNER, I've been more a fan of his
conceptual models than his implementations. The Actor stuff was
brilliant, and I remember some interesting conversations from my student
days at MIT (40 years ago, mind you) - but every time he releases some
kind of implementation, it confuses the heck out of me.

Miles Fidelman

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

[Ignas Vyšniauskas]

On Thu, Jun 26, 2014 at 2:08 AM, Richard A. O'Keefe <o...@cs.otago.ac.nz> wrote:
> http://carlhewitt.info has lots of links to papers &c but
> I am still searching in vain for the *expected* evidence
> that ActorScript is something other than vapourware.
>
> I say *expected* because the Actor model has been around for
> a long time, Hewitt is a highly respected researcher, and I
> trust him not to talk about ActorScript as an existing thing
> if it isn't.

If you go through the other papers listed on Hewitt's page you will
notice some interesting "publications", like:

* "Mathematics self-proves its own Consistency (contra Gödel et.
al.)", where Hewitt claims having disproved long established
mathematical results via some ad-hoc philosophical arguments;
* "What is computation? Actor Model versus Turing's Model", where he
argues that the Actor Model expresses hypercomputation and thus
transcends Turing machines;

and other gems of varying degree.

To put it lightly, I think Hewitt's papers published after circa 2000
should be taken with a grain of salt. If you look at his publication
history[1], you will notice he has not released a single paper in a
respectable (sic) journal since then. He has also been notoriously
banned from Wikipedia[2][3] for destructively editing articles
according to his own beliefs. I could go on with many other
"interesting" facts, but they can be easily discovered by oneself.
Respectability is not a permanent trait.

[1]: http://www.informatik.uni-trier.de/~ley/pers/hd/h/Hewitt:Carl
[2]: http://en.wikipedia.org/wiki/Wikipedia:Requests_for_arbitration/Carl_Hewitt
[3]: http://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/CarlHewitt/Archive

--
Ignas