HN Debrief

Excessive nil pointer checks in Go

  • Programming
  • Developer Tools
  • Static Analysis
  • Go
  • Type Systems

The post argues that a lot of Go nil checking is cargo-cult defensive programming. Its core claim is simple: if a function requires a dependency to work, passing nil is already a bug, so checking for nil deep inside business logic just spreads uncertainty through the codebase. The cleaner move is to reject invalid state where it enters the system, keep the rest of the code operating on valid assumptions, and panic or fail loudly when an internal invariant is broken instead of silently limping on.

Treat repeated nil checks as a design smell, not extra safety. If your codebase depends on invariants like "this dependency always exists," enforce them at construction or module boundaries and back that up with static analysis, not scattered defensive branches.

Discussion mood

Mostly agreeing with the design principle, but frustrated that Go makes it hard to encode or enforce. The mood was less about this specific blog post and more about long-running annoyance with nil, typed-nil interfaces, and Go’s lack of non-nullable references.

Key insights

  1. 01

    Go style rules cannot replace nullability

    Avoiding pointers, passing structs by value, and banning interface nil checks can reduce the blast radius of nil, but they do not solve the underlying expressiveness gap. Real code still needs shared mutable state, optional values, and library interop, and even supposedly stack-allocated values can escape to the heap through interfaces or logging calls like pkg log. The takeaway is that house rules help, but they are brittle without language support.

    If your team uses conventions like value types by default, document the exceptions and audit them with tooling. Also watch for hidden escapes in performance-sensitive code with compiler diagnostics such as `go build -gcflags="-m"`.

      Attribution:
    • Fire-Dragon-DoL #1
    • mirekrusin #1
    • ignoramous #1
  2. 02

    Static analysis is the practical backstop

    The closest thing to non-nullable types in Go today is external analysis. NilAway was called out as useful because it infers nilness without forcing pervasive annotations, while the comparison to Java’s JSpecify and NullAway highlighted the tradeoff: inferred checks catch bugs quickly, but explicit annotations communicate intent better. That framing shifts the solution from style advice to pipeline enforcement.

    If nil bugs are a recurring source of incidents, add a nil analyzer to CI instead of relying on code review to catch bad assumptions. Pair it with clear API docs about which values are allowed to be absent.

      Attribution:
    • retrodaredevil #1
    • p2detar #1
    • jchw #1
  3. 03

    Null should carry meaning or disappear

    Checking both `x != nil` and `!x.isEmpty()` was used as a wider example of the same mistake. If null and empty both mean "nothing here," carrying both states through the system just creates more branches and more opportunities to paper over bugs. Nil checks are easiest to justify at boundaries where an external system already imposed that ambiguity. Inside your own code, they usually signal an undefined contract.

    Collapse duplicate absence states early when ingesting data from external systems. Pick one internal representation for "missing" and make the rest of the code use it consistently.

      Attribution:
    • rzwitserloot #1
  4. 04

    Public constructors are still real boundaries

    The strongest criticism of the post was that it underplayed how often object construction itself is the boundary. If a type is public, callers are not forced through your happy-path setup code, and constructor argument validation is exactly where perimeter checks belong. Deleting those checks in the name of purity can make regressions harder to localize when initialization code changes later.

    Keep validation in public constructors and exported APIs even if upstream code already checks the same condition. Remove duplicate checks in private internal paths first, not at package boundaries.

      Attribution:
    • Joker_vD #1
    • ceving #1
    • galkk #1
  5. 05

    Option wrappers can force explicit handling

    One team sidestepped ambiguous nils by introducing a generic Optional type with JSON support. The useful part was not novelty but clarity: a plain `*SomeStruct` meant "pointer, but expected to exist," while `Option[*SomeStruct]` meant actual absence that callers had to unwrap. It is a weaker version of Rust’s `Option`, but it still makes intent visible in signatures instead of being buried in comments.

    If your domain has many truly optional fields or parameters, consider a small Option type for those cases rather than overloading raw pointers to mean both indirection and absence. Use it selectively so it sharpens contracts instead of adding ceremony.

      Attribution:
    • liampulles #1
    • autarch #1
  6. 06

    Fail fast beats sentinel fallthrough

    Several comments broadened the point beyond Go: if a required dependency or loaded object is missing, returning a zero value or silently skipping work usually creates worse failures later. The better pattern is to return an error at load time, then let downstream code operate on valid objects. That keeps the branch where the problem happened close to the code that can explain or recover from it.

    When an operation cannot produce a valid object, return an error there instead of manufacturing partially valid state. Reserve downstream checks for genuinely optional data, not failed initialization.

      Attribution:
    • glove2477 #1
    • guilhas #1

Against the grain

  1. 01

    Local reasoning still matters with AI-written code

    Even people who agreed that excessive defensiveness pollutes code argued that some redundancy is buying a different kind of safety. When humans or coding agents touch many call paths, local checks can make a function easier to trust in isolation and can stop an invalid assumption from propagating quietly. The sharper version of this point was not "keep all nil checks," but "never swallow the error without at least surfacing it loudly."

    If AI tools or large teams frequently edit the same code, keep especially important precondition checks near critical operations, but make failures explicit with errors or logs. Optimize for diagnosability before you optimize for elegance.

      Attribution:
    • zoogeny #1
    • bediger4000 #1
    • kissgyorgy #1
  2. 02

    Option types do not remove design work

    A few comments pushed back on the idea that Rust-style optional types magically solve this problem. They force you to unwrap earlier and more explicitly, which is useful, but they do not decide where the unwrap belongs. In more complex cases you can also end up modeling several different states, such as absent value versus present-but-null raw pointer, because those states are genuinely distinct.

    Do not expect a Maybe or Option abstraction to fix poor API boundaries by itself. You still need to decide where optionality ends and invariant-bearing code begins.

      Attribution:
    • throwa356262 #1
    • tialaramex #1 #2
    • 5701652400 #1

In plain english

heap ↩
A region of memory used for dynamically allocated values that outlive a single function call.
interface ↩
A Go type that can hold values of different concrete types as long as they implement a required set of methods.
JSpecify ↩
A Java project for standard nullness annotations so tools can reason about which references may be null.
nil ↩
Go’s zero value for pointers, interfaces, maps, slices, channels, and some function types, often used to mean either "missing" or "uninitialized".
NilAway ↩
An open source static analysis tool for Go from Uber that tries to detect nil-related bugs.
NullAway ↩
A Java static analysis tool that enforces null-safety rules based on code structure and annotations.
Option ↩
Another common name for an Optional type, popularized by languages like Rust.
Optional ↩
A type used to represent that a value may or may not be present, instead of using null or nil directly.
typed nil ↩
A nil value stored inside an interface along with type information, which can make the interface itself appear non-nil even though the underlying value is nil.

Reference links

Go nil analysis and tooling

  • NilAway
    Referenced as a practical static analyzer for catching potential nil dereferences in Go.
  • Structured logging with slog
    Mentioned to illustrate how passing values through interfaces or logging APIs can trigger heap escapes.

Language design comparisons

Related discussion link