[erlang-questions] Go vs Erlang for distribution

[unknown]

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]: Loading Image...: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.

[unknown]

Post by unknown
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.

Post by unknown
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.

[unknown]

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.

Post by unknown

Post by unknown
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,

Post by unknown
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.

Post by unknown
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.
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-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140621/f54b3599/attachment.html>

[unknown]

Post by unknown

Post by unknown
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>

Post by unknown
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

[unknown]

Post by unknown

Post by unknown

Post by unknown
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>

Post by unknown
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).

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

[unknown]

Post by unknown
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

[unknown]

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

Post by unknown

Post by unknown
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.
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
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140623/313acea4/attachment.html>

[unknown]

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

Post by unknown
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

Post by unknown

Post by unknown
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.
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
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140623/b83a3eb3/attachment.html>

[unknown]

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

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

Post by unknown
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

Post by unknown

Post by unknown
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.
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
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140623/bb6ed85e/attachment.html>

[unknown]

Post by unknown

In many ways an Erlang system does have an OS feeling about it. At least

I think so.
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.

[unknown]

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

Post by unknown

Post by unknown

In many ways an Erlang system does have an OS feeling about it. At

least

Post by unknown
I think so.
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
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140623/65ca6178/attachment.html>

[unknown]

Post by unknown
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

[unknown]

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


On Mon, Jun 23, 2014 at 2:17 PM, Ignas Vy?niauskas <i.vysniauskas>

On Mon, Jun 23, 2014 at 2:43 PM, Raphael Korsoski <psidrinal>

Post by unknown
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

Post by unknown
theorists, language theorists, mathematicians working in the Curry-Howard
domain and so forth, but for the general programmer the differences are

more

Post by unknown
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140623/89c80745/attachment.html>

[unknown]

Post by unknown
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.

[unknown]

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

Post by unknown
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

[unknown]

Post by unknown
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.

Post by unknown
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.

Post by unknown
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

Post by unknown
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

Post by unknown

In many ways an Erlang system does have an OS feeling about it. At least

I think so.
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
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.html>

[unknown]

Post by unknown
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. :-)

[unknown]

Post by unknown

Post by unknown
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

[unknown]

Post by unknown

Post by unknown

Post by unknown
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

[unknown]

Post by unknown
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.

[unknown]

Post by unknown

Post by unknown

Post by unknown

Post by unknown
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

[unknown]

Post by unknown
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.

[unknown]

Post by unknown

Post by unknown
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

[unknown]

Post by unknown

Post by unknown

Post by unknown
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.

-Craig

[unknown]

Post by unknown
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

[unknown]

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

Post by unknown
I think the more important aspect here being that its very hard to be

Post by unknown
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
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140625/51018026/attachment.html>

[unknown]

Post by unknown
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.

[unknown]

Post by unknown
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

[unknown]

On Wed, Jun 25, 2014 at 5:20 PM, Miles Fidelman <mfidelman>

Post by unknown

Post by unknown

Post by unknown
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

Post by unknown
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

Post by unknown
Thanks!
Miles
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140625/10c9c499/attachment.html>

[unknown]

Post by unknown
On Wed, Jun 25, 2014 at 5:20 PM, Miles Fidelman
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
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

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

Re.

Post by unknown
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

[unknown]

On Wed, Jun 25, 2014 at 6:56 PM, Miles Fidelman <mfidelman>

Post by unknown

Post by unknown
On Wed, Jun 25, 2014 at 5:20 PM, Miles Fidelman <
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
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

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

Post by unknown
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,
- 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).

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.

Post by unknown
- 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

Post by unknown
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

Post by unknown
Thanks,
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140625/17bb49f2/attachment.html>

[unknown]

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

[unknown]

Post by unknown
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

Post by unknown
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140625/d0c7d1d7/attachment.html>

[unknown]

Post by unknown
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.

Post by unknown
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. :-)

Post by unknown
- 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.

Post by unknown
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

[unknown]

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.

[unknown]

Post by unknown
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

[unknown]

Post by unknown
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

[unknown]

Post by unknown

Post by unknown
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.

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.

[unknown]

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.

Post by unknown
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).
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.
* 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
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
* 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
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
Hi,

-snip-

Post by unknown
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

[unknown]

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:
[1]http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/


--
Tristan Sloughter
tristan.sloughter





On Sat, Jun 21, 2014, at 03:43 PM, Alexei Sholik wrote:

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]: [2]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:
[3]http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-i
n-go.html
* increased activity on projects such as libswarm[2], libchan[3],
there are more.

[2]: [4]https://github.com/docker/libswarm
[3]: [5]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

_______________________________________________

erlang-questions mailing list

[6]erlang-questions

[7]http://erlang.org/mailman/listinfo/erlang-questions

References

1. http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/
2. https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large
3. http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html
4. https://github.com/docker/libswarm
5. https://github.com/docker/libchan
6. mailto:erlang-questions
7. http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140622/913de945/attachment.html>

[unknown]

On Sun, Jun 22, 2014 at 4:02 PM, Tristan Sloughter

I wrote a post about this recently because I found the idea of Go being an
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

[unknown]

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

Post by unknown
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

On Mon, Jun 23, 2014 at 12:02 AM, Tristan Sloughter <

Post by unknown
I wrote a post about this recently because I found the idea of Go being
http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/
--
Tristan Sloughter
tristan.sloughter
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).
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.
* 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
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
* 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
*_______________________________________________*
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
Google is a huge company that is spending a *lot* of effort in an attempt to

Post by unknown
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

[unknown]

Post by unknown
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.

Post by unknown
[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 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
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
* 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140625/1812350f/attachment.html>

[unknown]

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.

Post by unknown

Post by unknown
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.

Post by unknown
[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 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
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
* 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

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