Go Didn't Get Error Handling Right

I’ve finally found a way to put this concisely:

No, Go didn’t get this right. Returning a tuple (a T and an error) isn’t an appropriate tool when you want your function to return either a T or an error. It’s a brittle hack that requires everyone to use a third-party linter on top. Otherwise, that tuple is handled incorrectly too frequently.

All of that, because Go keeps ignoring a basic feature from the 1970s that allows to you express the “or” relationships (and nullability).

APIs that are easy to use incorrectly are bad APIs.

Appendix

To be clear:

• It’s a deep issue with the language capabilities that goes way beyond errors. It can’t be fixed by just changing the syntax .
• Exceptions don’t have this issue, but they have many other issues . I don’t recommend exceptions.
• I recommend the Result/Either types found in languages like Rust and Haskell.
• Go also got many other things wrong. Too many, in fact.
• Although, it got some things right and inspired progress in the field.

Related reading

Other people’s posts:

• “Falling Into The Pit of Success” - a design philosophy that’s very influential on me. Similarly short.
• “I want off Mr. Golang’s Wild Ride” - a classic Go rant based on the same philosophy. Long, not limited to error handling, has specific code examples.

My other posts about error handling:

1. “Rust Solves The Issues With Exceptions”
2. “Why Use Structured Errors in Rust Applications?”
3. “Go Didn’t Get Error Handling Right”

Discuss

• My original comment on Hacker News (the entire comment section is good, by the way)