3 ms·

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

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