"With a Go function, if you ignore the returned error, you still get the result - most probably a null pointer."

Well you should handle the error in the first place.

> Well you should handle the error in the first place.

That's like saying you should just write bug-free code in the first place.

Go goes out of its way to ensure you handle the error. You have to do something with that err return, otherwise it's a compile error. If you're just throwing it away without checking, we've gone from the mere mistakes everyday developers make to irresponsibility.

There's a reason most go code is littered with "if err != nil" on nearly all function calls.

Go does absolutely nothing to ensure you handle the error.

The only thing in Go source code that you see more often than the boiler plate "if err != nil" is "a, _ = foo()".

It's all too easy to ignore an error in Go.

Go has many community linters available, https://github.com/kisielk/errcheck is popular for checking unhandled errors.

If you'd like a combo-pack, check out https://github.com/golangci/golangci-lint which includes all of the popular linters in a configurable way.