For me it is Go vs Erlang. I see both solving similar set of problems (for me!).

The slides said Go is easier than Erlang. That is true in some aspects, namely syntax (Elixir to the rescue here!). Go is also easier because of static typing. Speed of compilation is awesome. Building to an executable that only depends on libc -- yes please! love that about Go.

I am scared about safety and fault tolerance. Ability to share memory is good for performance but a shared heap in a large concurrent application is scary to me. Not sure what I think about multiple channels and running select over them. Then it pseudo-randomly choosing one channel among those that can receive. Erlang's focus on processes/actors vs channel and each actor having a single mailbox somehow makes more sense to me. Having a shared heap mean faster data processing but GC cannot be fully concurrent.

Now passing channels inside other channels is cool, but also kind of scary to me. You can pass channels, inside channels, inside channels, can make some kind of a lazy computation chain.

Also I have been wondering, but couldn't find it by doing a quick search, is it possible to build supervision trees out of goroutines like one builds supervision trees in Erlang's OTP. Say I want to have a chat client goroutine to keep the chat up. But I want to monitor it in case it crashes (panics?) then then spawn another one perhaps. Is that possible?

As someone who has shipped production software in both Erlang and Go. They are very different beasts. Regarding error handling, Go is far closer to C than Erlang. If Erlangs slogan is "let it fail" and gives you the power to avoid writing error handling for every single thing, Go's is "don't let it fail" ... and you really need to write error handlers for everything, reducing the "unexpected" footprint.

There is no real way to grab a goroutine from the outside and tell it what to do -- you have to use its channels, which if bad things have happened are probably broken.. there are some systems built that catch exceptions and send messages (this is from inside the goroutine of course) on the channel, but I haven't used them.

That might come across an unduly negative of Go, but Go has major upsides. Great tooling, easy to understand after a tiny amount of time, a culture of explicit (even at times non-DRY) code, amazing deploy model, and generally just very understandable even to newcomers.

Interesting, thank you for explaining. The lack of monitoring of goroutines is certainly different.

> which if bad things have happened are probably broken.

It reminds me of Joe Armstrong's quote about how it is hard to perform surgery on yourself. In other words having the component that is failing trying to fix itself. I guess I would have to read more about design patterns. I saw a presentation about concurrency patterns in go, but it is about very simple toy examples, I am more interested in a larger concurrent applications, handling multiple connections for example.