[dymk]

And so it's clear to others, this probably the worst possible way for a language to go about implementing error handling (maybe aside from just not having any mechanism outright and terminating).

But alas, those are the choices that the Go language made.

[isodude]

Is it really though? I've tried out Exceptions in most languages and Go's error handling stuck out to me as the first one that is clear what it does, which of course is the mantra of the language.

[TheDong]

Exceptions are a strawman.

Compare it to another modern language such as rust. Go does not have a stdlib mechanism for converting error types into each other (akin to rust's Into), it doesn't have the idea of mapping values together (akin to rust's carrier operator which is basically like monad do syntax), it doesn't have a way to create a list of errors by default (akin to 'cause' in rust), it doesn't have a way to generate concrete error types for your functions (like the 'failures' or 'error-chain' libraries in rust, which can't be written in go due to a lack of macros and generics and sum types).

It doesn't have a way to match on all possible concrete error values (akin to 'match' in rust or other sum-type things) or to do thing slike '.and_then' or '.map_err' or so on.

Go's error handling is downright insulting in a language that wasn't built at the same time as c.