You cannot ignore the error return value in Go.

If you would think a bit more broadly, you might also see this so that all the error handling code is visible, explicit and right there with the actual logic, and not hidden away what might be (and often is) multiple layers of modules.

>You cannot ignore the error return value in Go.

that's not true. You can ignore the second parameter by explicitly naming it with an underscore, like this:

    x, _ := MightFail()

Well ok, you can explicitly ignore them, but not by being negligent.

it sounds bad in theory, but in practice it turns out to be quite good. It's actually the opposite; because you know that there's no exceptions, control flow is very obvious. Whether a function does or does not return an error is a part of its signature. You always know, when calling a function, if it may or may not return an error, and it is up to the caller to decide what to do with that error. As a result, there's no control flow pitfalls like forgetting to close a filehandle because an exception was thrown in some function that you didn't know could throw an exception.

>Did they kill stack traces too?

no, we have stack traces.

Also, it's Go, not GO.