Go's Error Handling Is Perfect

Go’s explicit error handling

• Many commenters like Go’s “errors as values” and explicit if err != nil checks.
• They argue it forces awareness of failures, encourages defensive programming, and makes which functions can fail obvious at call sites.
• Some appreciate that ignoring an error requires a visible _ or similar, which tooling can detect.

Critiques of Go’s approach

• Others say explicit checks don’t truly “force” thoughtful handling; developers can still blindly bubble errors up or ignore them.
• The repetitive if err != nil { return … } is viewed as noisy, making real logic harder to read.
• Some feel Go makes it hard or unidiomatic to distinguish error kinds, so code tends to just log and continue.

Comparisons with Python

• Several dispute the article’s claim that Python stack traces are too deep to be useful; they report good experiences, especially with newer Python versions.
• Many prefer exception-based code for small scripts and ad‑hoc tasks, where “fail with a trace” is acceptable and concise.
• Others argue deep nesting of try/except is an antipattern and that exceptions should usually be handled at a high level.

Comparisons with Rust and FP-style Result/Either

• Rust’s Result<T, E> plus ? is widely praised as combining explicitness with concise syntax.
• Sum types / Either monads with pattern matching are favored by some for forcing handling before accessing values.
• Commenters note Go’s lack of sum types and nil issues; they see result, err as a weaker, non-typed version of Result.

Stack traces, context, and debugging

• Some lament that idiomatic Go error returns lack automatic stack traces and file/line info.
• Others argue well-wrapped errors with contextual messages are higher signal than raw traces and that panics/debug tools or logging can provide stacks when truly needed.
• There’s disagreement on whether printing stack traces in production is good practice.

Backward compatibility and evolution

• Introducing a Result type into Go’s standard library is seen as appealing but fraught with compatibility and ecosystem split concerns.
• Several think Go’s system is “good enough” for most cases but lacks ergonomic sugar for complex error handling.