4 ms·

In Go you’d run a goroutine and then send either a result or an error over a channel. I’m curious what else would be needed for “robust” supervision of the goro

In Go you’d run a goroutine and then send either a result or an error over a channel. I’m curious what else would be needed for “robust” supervision of the goroutine like Elixir/Erlang? I haven’t really felt a need for anything more.

troupo 3y ago
What happens when a channel abruptly closes? Or when it throws an error? Erlang VM guarantees that [1] - all processes are isolated. Fatal error in one process will not affect other processes. Crucial: it will not affect the VM. - If you set up process monitoring, and that process dies for whatever reason the monitor will be notified, with the actual reason. This lets the monitor (the supervising process) decide what to do next: restart, do nothing, stop entirely etc. - Other relevant things like processes suspended when waiting for messages, or running out of reductions (number of allocated calls and messages) so that other processes can be executed, a bunch optimizations in the VM about CPU caches etc. So what you have is "kubernetes for processes, inside the VM". And the reason you don't have supervision for either Go or Rust is simple. Both Go and Rust for some completely asinine reasons decided that an unhandled error should kill the entire running application, with no chance of recovery. And later they both awkwardly bolted on a half-assed solution to catch panics. That's it. That's the extent of error handling and guarantees in those languages. Of course no one builds supervision trees there. [1] Of course it's not a 100% guarantee, nothing is, but other languages don't have even that.
- danenania 3y ago
  Thanks for the explanation. I see your point about panics, though using panics is rare in Go and not what would normally happen in a goroutine that has an error. If you know your goroutine won’t panic, getting the result or error from a channel seems sufficient in most cases, but it’s true that you can’t always know that.
  - troupo 3y ago
    The problem isn't about using panics, or "knowing that your goroutine won't panic". Things happen. Unhandled errors happen. Unhandled errors from processes happen :) Erlang'd documentation used to have a section called "Do not program defensively" [1] This is known as "let it crash" philosophy. Or, better put, that Erlang has auto healing mechanisms [2] When applied correctly, it significantly reduces the amount of boiler plate code you need to write because you're only concerned with the happy path in most of your code. [1] A copy is available here: https://docs.jj1bdx.tokyo/Erlang_Programming_Rules.html#HDR11 https://docs.jj1bdx.tokyo/Erlang_Programming_Rules.html#HDR1... [2] Erlang has auto healing mechanisms

troupo 3y ago

What happens when a channel abruptly closes? Or when it throws an error? Erlang VM guarantees that [1] - all processes are isolated. Fatal error in one process will not affect other processes. Crucial: it will not affect the VM. - If you set up process monitoring, and that process dies for whatever reason the monitor will be notified, with the actual reason. This lets the monitor (the supervising process) decide what to do next: restart, do nothing, stop entirely etc. - Other relevant things like processes suspended when waiting for messages, or running out of reductions (number of allocated calls and messages) so that other processes can be executed, a bunch optimizations in the VM about CPU caches etc. So what you have is "kubernetes for processes, inside the VM". And the reason you don't have supervision for either Go or Rust is simple. Both Go and Rust for some completely asinine reasons decided that an unhandled error should kill the entire running application, with no chance of recovery. And later they both awkwardly bolted on a half-assed solution to catch panics. That's it. That's the extent of error handling and guarantees in those languages. Of course no one builds supervision trees there. [1] Of course it's not a 100% guarantee, nothing is, but other languages don't have even that.

danenania 3y ago
Thanks for the explanation. I see your point about panics, though using panics is rare in Go and not what would normally happen in a goroutine that has an error. If you know your goroutine won’t panic, getting the result or error from a channel seems sufficient in most cases, but it’s true that you can’t always know that.
- troupo 3y ago
  The problem isn't about using panics, or "knowing that your goroutine won't panic". Things happen. Unhandled errors happen. Unhandled errors from processes happen :) Erlang'd documentation used to have a section called "Do not program defensively" [1] This is known as "let it crash" philosophy. Or, better put, that Erlang has auto healing mechanisms [2] When applied correctly, it significantly reduces the amount of boiler plate code you need to write because you're only concerned with the happy path in most of your code. [1] A copy is available here: https://docs.jj1bdx.tokyo/Erlang_Programming_Rules.html#HDR11 https://docs.jj1bdx.tokyo/Erlang_Programming_Rules.html#HDR1... [2] Erlang has auto healing mechanisms