[erlang-questions] Go vs Erlang for distribution

[Gleb Peregud]

In my opinion Go is not a right tool for almost any job. It falls
short in many areas:
- it ignores two decades of programming languages design research
- it does very poorly compared to other strongly typed statically
compiled language
- it has inconsistent type system
- it is absurdly verbose
- it's error handling is horrendous
- it is not a simple nor a small language
- it has too many special cases and exceptions in it's semantics
- no polymorphic data types (not to mention higher kinded polymorphism)
- etc.

In my opinion, in almost all uses of Go I heard, I am pretty sure
choosing either Erlang or Haskell would work much better.

With all engineering hours which were invested in Go, world could have
gotten a superb language instead of something so very mediocre.

On Wed, Jun 25, 2014 at 6:20 PM, John Haugeland <stonecypher@REDACTED> 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.
>
>
> The people switching from Erlang to Go weren't Erlang programmers.  They
> were multi-language programmers who heard about Erlang from news sites and
> social media, and were dabbling.  This is like thinking that Ruby is over
> because, for around a year, HN told them to switch to Twisted Python, or Go,
> or now Rust.
>
> Nope.  People come and people Go.  We had a brief wave of dilettantes from
> the WhatsApp sale.  G'bye.
>
> Dart isn't going to kill anything either.  It's a bunch of people "ooh" ing
> and "aah" ing at the Google name and some benchmarks that first show Go
> being faster than everything, and then later show Go catching up to and
> passing the things they previously claimed to be faster than.  (And still
> aren't as fast as.)
>
> If it's a fun language, try it.  We're in no danger though.
>
>
>
>
>>
>>   [1]: https://pbs.twimg.com/media/Bqr9xJJIgAIUewQ.png:large
>>
>> 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.
>>
>> Let me explain what suggests Go might be a viable alternative:
>>
>>   * the slide mentioned above
>>   * 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:
>> http://da-data.blogspot.co.uk/2013/02/teaching-distributed-systems-in-go.html
>>   * increased activity on projects such as libswarm[2], libchan[3], there
>> are more.
>>
>>   [2]: https://github.com/docker/libswarm
>>   [3]: https://github.com/docker/libchan
>>
>> If you haven't been keeping up with Go, here's a brief overview of its
>> principles:
>>
>>   * imperative, statically typed, garbage collected, lower level than
>> scripting languages, but higher level than C
>>   * builtin concurrency with lightweight processes (called goroutines)
>> which are scheduled cooperatively
>>   * single address space for all goroutines (modifying shared data is
>> discouraged, but possible); hence no isolation
>>   * goroutines have no identity, communication between them is only
>> possible through channels; hence no ability to monitor or link to
>> goroutines, so no supervision
>>   * 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
>>   * 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"
>>
>> 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?
>>
>> 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).
>>
>> 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.
>>
>> Thanks for reading this far.
>>
>> --
>> Best regards
>> Alexei Sholik
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>