March 2, 2026
Error Wars: Try-athlon
Why Go Can't Try
Go says no to “try” — fans split between “keep it simple” and “learn from Zig”
TLDR: Go isn’t adding a “try” shortcut because its error system is loose and unstructured, unlike Zig’s strict, compiler-checked approach. The community split fast: some slam Go’s “simplicity over engineering,” others defend caution and nuance, with jokes about “if err != nil” being daily cardio — it matters because it shapes how Go code is written.
Go’s no-try stance just lit up the comments, and it’s not about hating shortcuts — it’s about how Go handles mistakes under the hood. The article argues that Zig’s neat one-word “try” works because Zig knows exactly which errors can happen, while Go’s errors are loose and unstructured. Translation: Zig’s compiler is strict; Go’s vibe is “be explicit,” but it doesn’t actually make you be.
The crowd promptly divided. One camp rolled its eyes at Go’s “simplicity first” mantra — user cryptos called it simplicity over good engineering, pointing at “nil” checks and the long wait for generics. Another camp (advisedwang) said the Go team isn’t anti-sugar; they’re just waiting for a version of “try” that doesn’t confuse control flow and pleases, well, everyone. Then the nuance police arrived: fweimer reminded folks that some functions return both data and an error, so a universal “try” might paper over important details, linking to io.Reader.
Meanwhile, kbolino waved a big red flag about “sum types” — the fancy way to say a value could be this or that — clashing with Go’s rule that every type needs a default. And impure brought the flamethrower: Go only learns from C, try would be useful, and panics are messy. Cue memes: “C called, it wants its error handling back,” “if err != nil is my daily cardio,” and “nil is my manager now.” The vibe: Team Fewer Keystrokes vs Team Clear Exit Points — and nobody’s budging.
Key Points
- •Go has not added a try keyword; the commonly cited reason is concern over invisible exit points and control flow clarity.
- •Zig’s error handling is more explicitly enforced: function types indicate failure capability (!T), and the compiler requires exhaustive handling.
- •Go’s error type is an interface with Error() string, leading to unstructured errors and lack of compile-time knowledge of possible error returns.
- •Go relies on runtime conventions like errors.Is, errors.As, and fmt.Errorf("%w") rather than compiler guarantees for error propagation and inspection.
- •Zig uses finite, compiler-known error sets encoded as unique 16-bit integers; errors cannot carry payloads, so Zig uses an Error Return Trace for context.