<div dir="ltr"><div><div><div><div><div>Thank you all for the answers!<br><br></div>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.<br>

<br></div>One little nitpick I have is about zxq9's first reply which mentions:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Google is a huge company that is spending a *lot* of effort in an attempt to<br>


prevent yet another of their expensive toys winding up in the rubbish bin of<br>
digital history.<br></blockquote><br></div>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.<br>

<br></div>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.<br><br></div>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.<br>

<div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers!<br>Alex<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 12:02 AM, Tristan Sloughter <span dir="ltr"><<a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>




<div><div>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: <a href="http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/" target="_blank">http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/</a><span class="HOEnZb"><font color="#888888"><br>

</font></span></div><span class="HOEnZb"><font color="#888888">
<div><div> </div>
<div>-- <br></div>
<div>  Tristan Sloughter</div>
<div>  <a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a></div>
<div> </div>
</div></font></span><div><div class="h5">
<div> </div>
<div> </div>
<div>On Sat, Jun 21, 2014, at 03:43 PM, Alexei Sholik wrote:<br></div>
</div></div><blockquote type="cite"><div><div class="h5"><div dir="ltr"><div><div><div><div>Hi,<br></div>
<div> </div>
<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>

</div>
<div> </div>
</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).<br></div>


<div> </div>
<div>The reason for my asking on this particular list is twofold:<br></div>
<div> </div>
</div>
<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>

</div>
<div> </div>
</div>
<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>

</div>
<div> </div>
<div>  [1]: <a href="https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large" target="_blank">https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large</a><br></div>
<div><div> </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>

</div>
<div> </div>
<div>Let me explain what suggests Go might be a viable alternative:<br></div>
<div> </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 href="http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html" target="_blank">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></div>
<div> </div>
<div>  [2]: <a href="https://github.com/docker/libswarm" target="_blank">https://github.com/docker/libswarm</a><br></div>
<div>  [3]: <a href="https://github.com/docker/libchan" target="_blank">https://github.com/docker/libchan</a><br></div>
<div> </div>
<div>If you haven't been keeping up with Go, here's a brief overview of its principles:<br></div>
<div> </div>
<div>  * imperative, statically typed, garbage collected, lower level than scripting languages, but higher level than C<br></div>
<div>

  * 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> </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> </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>

</div>
<div> </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></div>
<div> </div>
<div>Thanks for reading this far.<br></div>
<div> </div>
<div><div><div><div><div>-- <br></div>
<div>Best regards<br></div>
<div>Alexei Sholik<br></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div></div><div class=""><div><u>_______________________________________________</u><br></div>
<div>erlang-questions mailing list<br></div>
<div><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br></div>
<div><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br></div>
</div></blockquote><div> </div>
</div>

</blockquote></div><br><br clear="all"><br>-- <br>Best regards<br>Alexei Sholik
</div></div></div></div></div>