I'm not at all defending the practice. I agree it's very easy to navigate around this. My answer is just the canonical one I've seen over and over again in books about Go.
It's not just that it's "very easy to navigate around this", it's that it's not true. The incorrect statement piggybacks on Go forbidding unused variables, however that has two absolutely major holes:
First, it requires having a variable in the first place, if you call a function for its side-effect and don't remember that it returns an error, Go won't tell you.
Second, Go only errors on dead variables, not dead stores, since conventionally the error variable is "err" you can easily forget to check one of them, and Go won't say anything because the err variable was read in one of the other checks.
It's even worse if you're one of the weirdoes which uses named return variables, because named return variables are always used:
func foo() (v int, err error) {
a, err := bar()
b, err := baz()
v = a + b
return
}
compiles just fine. But at least you're returning the second error. No such luck if you're using named return variables for documentation:
func foo() (v int, err error) {
a, err := bar()
b, err := baz()
return a + b, nil
}
