[erlang-questions] Go vs Erlang for distribution
Sun Jun 22 02:57:16 CEST 2014
On Sunday 22 June 2014 01:43:49 Alexei Sholik wrote:
> 2. In his recent talk at EUC Garrett Smith showed us an interesting
> slide where Go appears to be one of the primary alternatives to Erlang,
> as chosen by _Erlang programmers themselves_. To me this implies that
> Erlang programmers have found in Go some of the principles Erlang builds
> upon, the fact I'm going to dispute below.
I don't see that at all. There are Python, Common Lisp, OpenCL and D
frameworks that go a lot further toward emulating a distributed machine than
anything I've seen in Go. But they are external things, just like any
framework for distributed computing in Go would be. The syntax surrounding its
use would be the responsibility of that platform/library, and not really have
any inherently Go specific about it.
> So now comes the question: what do Erlang programmers think about Go
> stealing some of the mindshare (and job-share) in the area of building
> distributed systems? Why would if be a good option? Or not an option at
> all? Just professional opinions based on your experience with Erlang please.
An inflammatory question if there ever was. ;-)
Go is not, in my opinion, as compelling as Algol 68, D, Guile, Python or even
Ada for any particular problem domain. Neither was Java. And this is where the
historical parallel resides.
Google is a huge company that is spending a *lot* of effort in an attempt to
prevent yet another of their expensive toys winding up in the rubbish bin of
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:
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
More information about the erlang-questions