[tokenrove]

I've worked a bunch in both, and Go really doesn't compare; you can't judge based on watching a talk. I find it much, much easier to write safe, robust code in Erlang, and operationally, you have so much more power to inspect the state of the BEAM. Another key BEAM thing is the process heap, which amounts to region allocation when used carefully. The reduction mechanism used for scheduling processes, though crude, is also still much lighter-weight than Go's approach.

On the other hand, Erlang is a weird language and a weird environment, that takes a lot of time to really understand, so I understand why it's never going to "win", and golang tools and the runtime will continue to improve. YMMV.

[coder543]

> The reduction mechanism used for scheduling processes, though crude, is also still much lighter-weight than Go's approach.

I'm not sure how it could be lighter weight than what Go has implemented natively at the machine level, instead of in what amounts to a bytecode interpreter. If you have any links, I would be very interested to read more.

> I've worked a bunch in both, and Go really doesn't compare

I respect your experience, so it is probably a failure of imagination on my part that I simply can't imagine how the BEAM tools could be that much better. I haven't had a problem with a rogue task (or really anything else) in production with Go where I was unable to figure out what was going on extremely quickly. The tooling has been amazing for me, unlike basically every other language I've worked seriously with. The YouTube talk certainly didn't do the BEAM tools justice if they are that much better.

With Go, I actually get really nice GUIs to look around the running Go process and analyze the situation, instead of just an interactive CLI session where I have to craft my own commands to find the top tasks and such. The Go pprof tools also work as an interactive shell (but for analysis, not for remote arbitrary code execution), but I would rather just have the flamegraph in front of me 99% of the time. I fully admit that I've never had a chance to use Erlang/Elixir/BEAM in any meaningful way, but I have tried to understand what they offer, and I haven't seen the compelling magic that some people talk about.

Now, if someone is running a Go service without the HTTP pprof server running on some port that they can access, then yes... it wouldn't even come close to comparing to what BEAM offers when you have the option to connect to a running BEAM instance.

[tokenrove]

And, note, I'm not saying Go is bad, here, just that there is a lot that is underrated and misunderstood about Erlang.

On the Erlang side, check out the BEAM Book chapter on scheduling: https://blog.stenmans.org/theBeamBook/#CH-Scheduling and the core scheduling loop in the BEAM: https://github.com/erlang/otp/blob/master/erts/emulator/beam...

On the Go side, check out https://github.com/golang/go/tree/master/src/runtime/proc.go and the asm* implementations.

It's been a little while since I looked at it, but I recall that much less state had to be saved in an Erlang process switch in the usual case; I seem to recall it can be done in a handful of instructions in many cases. Go of course has to save a bunch of registers much as you'd have to do in any native context switch.

Edited to add: it can be useful to look at that part of the BEAM disassembled in objdump or gdb, to appreciate it, since it's hard to tell how much work is happening with all those macros.

[sodapopcan]

I only started with Elixir in recent months and it's the first language that has ever made me comfortable about writing concurrent code. I didn't spend a lot of time with Go, but the idea of just calling a function that is now running in parallel but was always disconcerting to me. Of course, I could have spent more time with it and gotten more comfortable learning the ins-and-outs, but Erlang/Elixir's addressable processes running with their own stack/heap/gc and passing messages between each other is something that clicked very quickly with me. It's such an incredibly simple idea. For being a "weird" language, I think there is a lot of power the simplicity of its design, especially around learning. You just have to get over the weird syntax (which is a hot topic).

For transparency, I've never written any production code in either Elixir or Go.

[rightbyte]

The funny thing is that Erlang is the Ericsson language. Go is the Google language.

Ericsson never had the Google "street cred" or K& not R. Ericsson is boring phone interchanges and boring radio. Google was hipster latte with software freedom before it turned out to be worse than MS, IBM and Oracle combined.

One might wonder what could have been without all the smoke and mirrors.