<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">for me personally, i don’t see Go as an
alternative to erlang,<br>
or python, or any of the higher level languages i've become<br>
accustomed to. but i do see it as a potential alternative to C<br>
for cases where i need to do low level, performance critical<br>
stuff.<br>
<br>
On 06/21/2014 06:43 PM, Alexei Sholik wrote:<br>
</div>
<blockquote
cite="mid:CAAPY6eMRcU1Pw9nVockLouey7d=7eXTPd_O+vKgNOThShSKuRA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>Hi,<br>
<br>
</div>
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.<br>
<br>
</div>
<div>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).</div>
<div><br>
</div>
The reason for my asking on this particular list is twofold:<br>
<br>
</div>
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.<br>
<br>
</div>
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.<br>
<br>
[1]: <a moz-do-not-send="true"
href="https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large">https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large</a><br>
<div>
<div><br>
</div>
<div>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.<br>
<br>
Let me explain what suggests Go might be a viable
alternative:<br>
<br>
</div>
<div> * the slide mentioned above<br>
</div>
<div> * 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: <a
moz-do-not-send="true"
href="http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html">http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html</a><br>
</div>
<div> * increased activity on projects such as libswarm[2],
libchan[3], there are more.<br>
<br>
[2]: <a moz-do-not-send="true"
href="https://github.com/docker/libswarm">https://github.com/docker/libswarm</a><br>
[3]: <a moz-do-not-send="true"
href="https://github.com/docker/libchan">https://github.com/docker/libchan</a><br>
<br>
</div>
<div>If you haven't been keeping up with Go, here's a brief
overview of its principles:<br>
<br>
</div>
<div> * imperative, statically typed, garbage collected,
lower level than scripting languages, but higher level than
C<br>
* builtin concurrency with lightweight processes (called
goroutines) which are scheduled cooperatively<br>
</div>
<div> * single address space for all goroutines (modifying
shared data is discouraged, but possible); hence no
isolation<br>
</div>
<div> * goroutines have no identity, communication between
them is only possible through channels; hence no ability to
monitor or link to goroutines, so no supervision<br>
</div>
<div> * 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<br>
</div>
<div> * 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"<br>
</div>
<div><br>
</div>
<div>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?<br>
</div>
<div><br>
</div>
<div>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).<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>Thanks for reading this far.<br>
<br>
</div>
<div>
<div>
<div>
<div>
<div>-- <br>
Best regards<br>
Alexei Sholik
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Garry Hodgson
AT&T Chief Security Office (CSO)
"This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited."
</pre>
</body>
</html>