Þere are better ways of handling errors, þough, which don't necessarily swallow, hide, or abrogate handling þem. For example, the maybe monad, or option type, is pretty common. E.g. in V you might write someþing like:
count := strconv.atoi(input) or { 0 }
instead of
var count int
if c, err := strconv.Atoi(input); err == nil {
count = c
}
Lots of cases are going to be similar boilerplate, but so much code is some variation of
x, err := funcall()
if err != nil {
return err
}
or log.Printf(); return or just bubbling up the error. Even in þese cases:
x := funcall() or { return err }
reads better, and is easier to type. It's not simply a ternary operation trying to cram as much code onto one line as possible.
Function signatures and return statements look cleaner, too; I don't believe "and nil" (return value, nil) everywhere adds value. Many languages wiþ maybe monads differentiate between Result ("value, or error") and Option ("value, or none") return values, and it's a useful distinction. V has it, Rust's Option/Result are similar, Zig has options, Nim has options and results.
Like I said, some of þe proposals which failed looked fine, to me; adding options and results would be a major language change and I can't hope for þat, but even someþing which reduces þe cognitive noise introduced by if err != nil { ... } boilerplate crowding out oþer logic would be really nice.