Erlang isn't necessarily better than Go in this regard. Since Erlang is interpreted and everything has to copied between processes, Go is bound to be faster than Erlang, especially when it comes to parallelism. Go is also statically typed, which in my experience makes it easier to avoid bugs in large teams.

Erlang, however, is much better at distributed concurrency. There are few who suits this use case better.

As in all cases. Use the best tool for the job.

Erlang is actually compiled, and binaries above a certain size are reference-counted rather than copied between processes. It still makes various compromises like using bignums and doing preemptive scheduling which make it slower in general.

It's compiled to erlang bytecode, yes, but not to machine code. You do have the option of doing that, but I do believe you miss out on live updates? Not sure.

Erlang is great though, especially Elixir, but for some use cases Go is better.

If the first paragraph is the extent of your concerns with Erlang (which are reasonable), they are more than addressed by Haskell. Compiled and very statically typed.

Yeah, but it's more difficult to teach others Haskell (what's a monad?) than Go. I know all three languages, I mostly prefer Go for backend work because it's easier for others to join in on.

Point is that they all have their strengths, but one is not necessarily better than the other. As with all things digital, it depends.

> Precisely as I said, "The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives"

I commented before your edit. The question I responded to was something like "What can you do in Go that you can't do in C++ or Java?"

> 99% of projects don't need green threads.

Perhaps not need, but many of those projects are paying a large opportunity cost in today's no-free-lunch, multicore, I/O-bound world.

> But for those that do, I'd much rather use a language better suited to the purpose, like Haskell or Erlang.

I dispute that Haskell or Erlang are better suited for the purpose. And good luck finding Haskell and Erlang developers.

> This isn't a very convincing argument for Go.

I disagree.

> And good luck finding Haskell and Erlang developers.

Unless you need a massive number of developers, or you're located out in the middle of nowhere, it really shouldn't be too difficult.

I disagree.

Have you tried hiring Erlang or Haskell developers? It's not like they don't exist. In fact, there are likely many developers that would love to take an Erlang or Haskell job, but there aren't that many opportunities.

I don't dispute that they exist, I dispute the economics of finding them compared to finding or training new Go developers. Frankly, no one is going to replace their entire team and start a hiring campaign because Haskell or Erlang (arguably) make concurrency slightly easier than Go.

You would be surprised by the result. Economically it make sense. And i would argue that production ready Elixir/erlang is easier to teach than production ready Go.

Still, I'm fairly risk averse. I'll wait for the inevitable explosion of Erlang/etc shops to take off before I jump on board.

It happened. But well. Do as you want. It is your project :)