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 B

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 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/beam_emu.c#L583 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 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.