[erlang-questions] Go vs Erlang for distribution

[Felix Gallo]

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

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

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

F.


On Sat, Jun 21, 2014 at 5:57 PM, zxq9 <zxq9@REDACTED> wrote:

> On Sunday 22 June 2014 01:43:49 Alexei Sholik wrote:
> >   2. In his recent talk at EUC Garrett Smith showed us an interesting
> > slide[1] where Go appears to be one of the primary alternatives to
> Erlang,
> > as chosen by _Erlang programmers themselves_. To me this implies that
> > Erlang programmers have found in Go some of the principles Erlang builds
> > upon, the fact I'm going to dispute below.
>
> I don't see that at all. There are Python, Common Lisp, OpenCL and D
> frameworks that go a lot further toward emulating a distributed machine
> than
> anything I've seen in Go. But they are external things, just like any
> framework for distributed computing in Go would be. The syntax surrounding
> its
> use would be the responsibility of that platform/library, and not really
> have
> any inherently Go specific about it.
>
> > So now comes the question: what do Erlang programmers think about Go
> > stealing some of the mindshare (and job-share) in the area of building
> > distributed systems? Why would if be a good option? Or not an option at
> > all? Just professional opinions based on your experience with Erlang
> please.
>
> An inflammatory question if there ever was. ;-)
>
> Go is not, in my opinion, as compelling as Algol 68, D, Guile, Python or
> even
> Ada for any particular problem domain. Neither was Java. And this is where
> the
> historical parallel resides.
>
> Google is a huge company that is spending a *lot* of effort in an attempt
> to
> prevent yet another of their expensive toys winding up in the rubbish bin
> of
> digital history.
>
> Sun went to the exactly the same effort -- to hype a language and pet VM.
> Their focus on marketing (as opposed to technology) was so complete that it
> successfully warped our vocabulary about "objects" to meet their product
> while
> doing nothing to make their product advance the state of the art. That the
> industry and academia largely went along with this says more about human
> nature than technology.
>
> Google, able to control a large percentage of what the majority of us see
> and
> hear, may be capable of the same trick.
>
> I don't see Go as offering anything new. At all. Erlang is a decent
> language,
> but as you noted, that's not the real magic as its more an artifact of the
> history of the platform's implementation than anything else. The important
> thing is the platform and the complete way in which it embraces the Alan
> Kay
> sense of "objects" (and that term being so loaded and meaningless now, has
> been avoided in favor of "processes"). The Erlang platform is better
> because
> it requires that I do less work to get that sort of functionality. It
> emulates
> a distributed machine in a world where the hardware market has been pushed
> toward One Arch to Rule Them All.
>
> And that means that Go is yet another Algol descendant that I would be
> forced
> to learn for very little gain. Go doesn't have anything new to teach me
> about
> problem decomposition, expression of my intuitions about process, or
> formalization of either. Erlang's platform, on the other hand, enables a
> radically different way of thinking about these things. This is probably
> the
> most important thing I can say about a language or platform.
>
> This is an older, but quite interesting, article:
> http://cowlark.com/2009-11-15-go/
>
> Anyway, I hope people who find Go a comfortable sytnax to write their Algol
> programs in use it to great effect. I'll adapt to that whenever I wind up
> working on something I care about that is already written in Go -- just
> like I
> have with Ruby, C++, D, Perl, etc. Placing too much emphasis on the
> difference
> is, in my opinion, a waste of effort -- because it doesn't help me get work
> done.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> 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.htm>