4 ms·

Curious how much people think Go will eat into Erlang? Many of the points made were about Erlang as CSP and that's Go-territory. Loïc Hogun (author of Cowboy,

Curious how much people think Go will eat into Erlang? Many of the points made were about Erlang as CSP and that's Go-territory. Loïc Hogun (author of Cowboy, other projects) said: For me Erlang is first fault tolerant, then concurrent, then functional As Go gains libraries like groupcache will it become more and more go-to for networked and shared systems? Is Go moving up from concurrent to fault-tolerant in a real way?

davidw 12y ago
If you dig around in HN's search there are a lot of good comments from people like jerf on the differences: https://news.ycombinator.com/item?id=5451916 https://news.ycombinator.com/item?id=5451916 https://news.ycombinator.com/item?id=7943248 https://news.ycombinator.com/item?id=7943248 But there are more here and there if you hunt for them. I think for things where they are sort of similar, Go will definitely be the more successful language because it looks so much more familiar and because it's moving faster with more momentum, at this point. I'm using Erlang for a semi-embedded thing at the moment, though, where stability is more important.
- Ixiaus 12y ago
  For what kind of embedded thing? We're using it for embedded things too...
- polskibus 12y ago
  Whenever I think about Erlang's stability I recall the problems mentioned by CouchDB authors and RabbitMQ users. Apparently CouchDB hit some problems with low level disk access that they couldn't trace and that pushed them to migrate away from Erlang. RabbitMQ is allegedly dropping lots of messages for unknown reasons under heavy use. I do not have the links at hand for reference but such stories make me wonder how battle-tested Erlang really is when you need to persist your data (and not just transmit it over the network).
  - Ixiaus 12y ago
    The Riak guys have better experience here and I would argue that it's pretty well battle-tested when Apple is deploying hundred node Riak clusters for production :) (Riak is built on-top of Erlang)
edgurgel 12y ago
I like this blog post (http://blog.erlware.org/some-thoughts-on-go-and-erlang/ http://blog.erlware.org/some-thoughts-on-go-and-erlang/) as it talks about some of the differences about them. For some of these reasons I don't think they solve the same issues and one won't eat the other.
Xorlev 12y ago
I think Go has a long way to (forgive the pun) go before it can really start to compete with the entire Erlang ecosystem. Only having a modest knowledge it both, Erlang is still built around stability. Hot code patching, an extremely instrumentable VM, the whole OTP framework, simple networked Actors. Erlang was built with telecom in mind. That's not to say they can't inhabit a lot of the same areas, but Go's area of interests will probably remain somewhat separate from Erlang.
tormeh 12y ago
I would take a look at akka instead. Distributed actor concurrency and local STM.. Oh my.
- bfrog 12y ago
  All built on the JVM which has its own set of issues compared to BEAM or natively compiled Go or Rust.
  - tormeh 12y ago
    Yeah, both Java and (currently) Scala are imperfect host languages as well. Global GC is not ideal. Everything's not golden, and it's not better than Erlang in general, but Scala+akka is really awesome for a lot of tasks. For most people looking at Erlang, Scala+akka will be more suitable, I think. Still, if I were to write something powering some really reliability-heavy stuff (like telecom stuff) I would probably go with Erlang.
    - dragonwriter 12y ago
      Scala+akka may be easier for Java programmers looking at Erlang, and perhaps enough so to make it "more suitable" when you look at net cost/benefit. OTOH, coming from other directions -- particularly dynamic languages -- Erlang may be easier, as well as its other advantages.
      - muraiki 12y ago
        For people coming from dynamic languages, especially Ruby, it's worth looking at Elixir. Elixir runs on the Beam VM (same as Erlang) and is fully Erlang compatible while fixing many of Erlang's warts, including offering a Ruby-inspired syntax and macros. Here's a fun introduction: http://howistart.org/posts/elixir/1 http://howistart.org/posts/elixir/1
        dragonwriter 12y ago
        I agree that its worth looking at (and I need to find time to take another swing at it), but I have to admit that when I came into it from Ruby (having also had some experience with Erlang, but not need), I found the Ruby-like syntax with very different semantics an obstacle rather than a help -- it had a kind of "uncanny valley" effect.
Ixiaus 12y ago
Go will not eat into Erlang. Go's type system is deplorable and an embarrassment, it lacks a virtual machine to do the things Erlang can do, it lacks all of OTP, etc... What I do see eating into Erlang is Scala and Akka, though.
nosequel 12y ago
Having used both, I don't think Go and Erlang are even close in comparison. Go's lack of go routine isolation and error handling will never allow it to properly handle the problems Erlang was designed for without a lot of defensive programming and pain. Start 20,000->30,000 go routines and have one of them crash, taking down the other 29,999 go routines and now try and debug that problem in production? Go tries to advertise that it was built writing important services in, but it's shared everything model really argues against that. Erlang's hot code loading, runtime inspection, production quality REPL, and process isolation makes it a completely different language than Go. Until Go routines and channels get way way better, I would never attempt to write a distributed server that needs high availability in Go, it is just too fragile atm. On the other side of the coin, if I wanted to write a simple command line tool quickly that was easy to deploy to many servers, Go might be a great choice, where Erlang is a bit painful for small and simple programs.

davidw 12y ago

If you dig around in HN's search there are a lot of good comments from people like jerf on the differences: https://news.ycombinator.com/item?id=5451916 https://news.ycombinator.com/item?id=5451916 https://news.ycombinator.com/item?id=7943248 https://news.ycombinator.com/item?id=7943248 But there are more here and there if you hunt for them. I think for things where they are sort of similar, Go will definitely be the more successful language because it looks so much more familiar and because it's moving faster with more momentum, at this point. I'm using Erlang for a semi-embedded thing at the moment, though, where stability is more important.

Ixiaus 12y ago
For what kind of embedded thing? We're using it for embedded things too...
polskibus 12y ago
Whenever I think about Erlang's stability I recall the problems mentioned by CouchDB authors and RabbitMQ users. Apparently CouchDB hit some problems with low level disk access that they couldn't trace and that pushed them to migrate away from Erlang. RabbitMQ is allegedly dropping lots of messages for unknown reasons under heavy use. I do not have the links at hand for reference but such stories make me wonder how battle-tested Erlang really is when you need to persist your data (and not just transmit it over the network).
- Ixiaus 12y ago
  The Riak guys have better experience here and I would argue that it's pretty well battle-tested when Apple is deploying hundred node Riak clusters for production :) (Riak is built on-top of Erlang)

edgurgel 12y ago

I like this blog post (http://blog.erlware.org/some-thoughts-on-go-and-erlang/ http://blog.erlware.org/some-thoughts-on-go-and-erlang/) as it talks about some of the differences about them. For some of these reasons I don't think they solve the same issues and one won't eat the other.

Xorlev 12y ago

I think Go has a long way to (forgive the pun) go before it can really start to compete with the entire Erlang ecosystem. Only having a modest knowledge it both, Erlang is still built around stability. Hot code patching, an extremely instrumentable VM, the whole OTP framework, simple networked Actors. Erlang was built with telecom in mind. That's not to say they can't inhabit a lot of the same areas, but Go's area of interests will probably remain somewhat separate from Erlang.

tormeh 12y ago

I would take a look at akka instead. Distributed actor concurrency and local STM.. Oh my.

bfrog 12y ago
All built on the JVM which has its own set of issues compared to BEAM or natively compiled Go or Rust.
- tormeh 12y ago
  Yeah, both Java and (currently) Scala are imperfect host languages as well. Global GC is not ideal. Everything's not golden, and it's not better than Erlang in general, but Scala+akka is really awesome for a lot of tasks. For most people looking at Erlang, Scala+akka will be more suitable, I think. Still, if I were to write something powering some really reliability-heavy stuff (like telecom stuff) I would probably go with Erlang.
  - dragonwriter 12y ago
    Scala+akka may be easier for Java programmers looking at Erlang, and perhaps enough so to make it "more suitable" when you look at net cost/benefit. OTOH, coming from other directions -- particularly dynamic languages -- Erlang may be easier, as well as its other advantages.
    - muraiki 12y ago
      For people coming from dynamic languages, especially Ruby, it's worth looking at Elixir. Elixir runs on the Beam VM (same as Erlang) and is fully Erlang compatible while fixing many of Erlang's warts, including offering a Ruby-inspired syntax and macros. Here's a fun introduction: http://howistart.org/posts/elixir/1 http://howistart.org/posts/elixir/1
      - dragonwriter 12y ago
        I agree that its worth looking at (and I need to find time to take another swing at it), but I have to admit that when I came into it from Ruby (having also had some experience with Erlang, but not need), I found the Ruby-like syntax with very different semantics an obstacle rather than a help -- it had a kind of "uncanny valley" effect.

Ixiaus 12y ago

Go will not eat into Erlang. Go's type system is deplorable and an embarrassment, it lacks a virtual machine to do the things Erlang can do, it lacks all of OTP, etc... What I do see eating into Erlang is Scala and Akka, though.

nosequel 12y ago

Having used both, I don't think Go and Erlang are even close in comparison. Go's lack of go routine isolation and error handling will never allow it to properly handle the problems Erlang was designed for without a lot of defensive programming and pain. Start 20,000->30,000 go routines and have one of them crash, taking down the other 29,999 go routines and now try and debug that problem in production? Go tries to advertise that it was built writing important services in, but it's shared everything model really argues against that. Erlang's hot code loading, runtime inspection, production quality REPL, and process isolation makes it a completely different language than Go. Until Go routines and channels get way way better, I would never attempt to write a distributed server that needs high availability in Go, it is just too fragile atm. On the other side of the coin, if I wanted to write a simple command line tool quickly that was easy to deploy to many servers, Go might be a great choice, where Erlang is a bit painful for small and simple programs.