Not just scheduling — the ability to forcibly terminate processes itself is a key part of why Erlang can be resilient to failures. It's a key area where I thin

Not just scheduling — the ability to forcibly terminate processes itself is a key part of why Erlang can be resilient to failures. It's a key area where I think Go went wrong. Without the ability to kill a goroutine, you can't implement caller-enforced timeouts and canceling — anything that should be able to be canceled has to explicitly check for some signal sent by the controlling party. This is why Go ended up with Context, which infects everything it touched. And you also can't create Erlang-style supervisor trees; you can't create self-repairing hiearchies of control. And you can't do things like use a debugger to attach to a process and terminate runaway goroutines.