
Go vs. Erlang for distribution - xkarga00
https://groups.google.com/forum/#!topic/erlang-programming/nFWfmwK64RU
======
zaphar
I've never really understood the desire to compare Go and Erlang. They serve
radically different purposes. The only thing they share are
processes/goroutines (or greenlets, green threads, fibers, whatever you want
to call them). A cheap small footprint concurrency primitive.

Go was created to make buildng a single server (in the software not hardware
sense) easier.

Erlang was created to create systems for managing a lot of servers with a
complicated dependency hierarchy.

Go doesn't have OTP and a fault tolerant runtime because Google has all that
stuff at a separate layer in their datacenters and the Go engineers didn't
feel a need to solve that problem. They wanted to solve the problem of still
having to build http servers in C++ for performance and all the attendant
annoyances that brings.

If I were going to build a massive distributed system today I'd use the Erlang
runtime to manage the overall system in a fault tolerant way and I'd use Go to
build the components.

They complement themselves well but they don't really replace each other.

~~~
mratzloff
A cogent response. I didn't get far into the thread because it seemed like no
one had any significant experience in Go and therefore they were not qualified
to debate each language's relative merits. Maybe it improved after the point I
stopped.

~~~
zaphar
It's more cogent I think because I'm a fan of both languages and have done non
trivial work in both.

The thread was short on people with both experience in Go and with knowledge
of the motivations for Go.

------
oinksoft
Loïc Hogun (author of Cowboy, other projects) hits the nail on the head:

    
    
      For me Erlang is first fault tolerant, then concurrent,
      then functional, yet for many people it seems to be the
      opposite order. I personally care very little about
      Erlang being functional (though I do care a great deal
      about immutability and pattern matching being the default
      behavior, the rest not so much), and the concurrency is
      nice but only because it enables all the fault tolerance
      features of the language.
    

I've yet to encounter anything as good as OTP for building fault-tolerant
systems. Go is not designed for safety like Erlang/OTP, and as far as I know
there is no concept of supervision with Go routines/channels, etc.

Go is no "ultimate antagonist to Erlang" as OP hypothesized.

~~~
craigyk
yup, but Go sure would be nicer if they added some good pattern matching...

------
davidw
Here's another kind of interesting/kind of flamey one:

Node.js vs Erlang: [https://groups.google.com/forum/#!msg/erlang-
programming/ufN...](https://groups.google.com/forum/#!msg/erlang-
programming/ufNoiKcx1N0/L9o5Wvh7Um4J)

I think the Erlang guys are not very good at marketing (in the broad sense)
their system, which is a pity, because Erlang is very nice for some kinds of
applications.

~~~
mononcqc
It's very hard to market a system when the first (and often last) comment on
it is inevitably about the syntax, which isn't going to change after 25 years
or so, let's be honest, no matter unimportant it may be in the long run.

~~~
gbhn
I don't understand defenses of programming languages which seem to assume that
syntax isn't a central issue. Syntax is _the_ central issue of a programming
language -- they all have very similar capabilities, in the end (thanks Alan
Turing), and the core of a language is in how those capabilities are expressed
in the syntax.

If most people find the syntax any of {awkward, intimidating, unreadable,
inscrutable, undesirable} then they won't use it unless they have to.

This means programming languages are path-dependent. Perhaps in a different
world, lisp-type syntax is how people think about programming. Or maybe in a
different world Haskell syntax is the norm. But we live in _this_ world, and
in this world, such syntax is pretty much all of the above. This makes it
_harder_ for people to read and understand programs written in those
languages. Since that's ultimately the central point of a programming language
-- to make programs readable to human beings -- syntax is the primary thing on
which languages are evaluated.

Obviously there are other factors like available libraries, tools, platform
support, and so forth, but syntax is an extremely important pillar.

~~~
mononcqc
_Semantics_ is the central issue of programming languages, not syntax.

The syntax defines the form of a valid program, but gives no information about
what it means. Semantics define what the execution of that program would be.

For example, 'X = X+1' can be valid by the syntax of two languages, except one
of them (say Erlang), will fail to do the pattern matching defined under
operator '=', whereas the other will do an assignment where 'X' is now worth
its former value plus one.

There is a lot more meaning and deeper implications to defining what 'x = x+1'
means than defining how to write it. Another example can be '1 + 3 * 5': this
is an addition and a multiplication, but what's the operator precedence? In
smalltalk, it would be '(1 + 3) * 5'. In forth it has another entirely
different meaning.

You can think of it this way: Erlang the language can have a mostly-equivalent
semantic set of operations in LFE, which is a lisp. It could have had semantic
equivalence with Elixir's syntax, but it didn't (because Elixir made different
decisions with re-binding and whatnot).

Even if Erlang had Elixir's syntax, it doesn't mean you'd have to stop caring
about: pattern matching, recursion, shared-nothing, etc.

Syntax is important, but it's not nearly as important or challenging as
semantics are.

------
saraid216
So, while that was... odd, there were some links buried in there that I found
to be interesting reading:

[http://carlos-trigoso.com/2014/03/07/out-of-the-labyrinth-
of...](http://carlos-trigoso.com/2014/03/07/out-of-the-labyrinth-of-
metaphysics-v-001/) (Or the Abstractitude of the Hewitt Actor Model.)

[http://jlouisramblings.blogspot.se/2012/10/ramblings-on-
thes...](http://jlouisramblings.blogspot.se/2012/10/ramblings-on-thesis-of-
bjarne-dacker.html) (Or a summary of the original problems Erlang was trying
to address.)

