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