[jcelerier]

> In Go, if a function returns an error you have to explicitly handle or suppress it. Otherwise code just doesn't compile.

ah, yeah, great idea. in practice this just means that most Go projects are minefields of

    if err != nil { panic(err) }

or

    if err != nil { return err }

ie a manual & repetitive implementation of assert for the first case and manual & repetitive implementation of an exception call stack for the second. thank you very much, I'll take the automated version known as exceptions instead.

[weberc2]

Yes, Go requires explicit error propagation, but this is desirable because 1) errors are no different than other values so they don’t get special flow control and 2) people are much more likely to properly handle errors if they have to think about handling in every call frame (I.e., error handling bugs are much rarer in Go than Python or JS or etc).

[_ZeD_]

>>> (I.e., error handling bugs are much rarer in Go than Python or JS or etc).

[citation needed]

[weberc2]

I've been writing Python extensively for 10 years and Go for 6. Recently, I've been the exceptions cop in our Python/JS shop, and every week I see errors in prod that would almost certainly not exist in Go code (both because Go is statically typed but also because Go developers check their errors).

Take this anecdote for whatever it's worth to you.