TL;DR
The author revisits Tony Hoare’s label of null references as a “billion dollar mistake,” arguing the claim is hyperbolic and that null dereferences are among the easiest invalid-memory bugs to detect. Removing or forbidding nil pointers carries nontrivial trade-offs—especially for systems-level languages like Odin—around initialization, performance, and intended programming style.
What happened
The piece examines the longstanding criticism of null pointers, starting from Tony Hoare’s remark that null references caused extensive damage. The author regards the monetary figure as hyperbole and frames null as one specific kind of invalid memory address—often used as a sentinel zero value—and not necessarily the dominant memory-safety problem in systems languages. He argues null dereferences are usually simple to find at runtime and frequently stem from trivial bugs, while other memory errors (use-after-free, bad pointer arithmetic, unmapped memory) are both more varied and harder to handle. The Odin language intentionally retains nil pointers and default zero-initialization to preserve a C-like programming model; the author says alternatives—forcing checks on every pointer use or requiring explicit initialization everywhere—have costs, including increased programmer burden and potential O(N) initialization costs where zeroing could be O(1). Odin provides Maybe(^T) for optional values, but the author says it is rarely needed in practice.
Why it matters
- Language design choices about nil and initialization entail trade-offs between safety, ergonomics, and performance.
- Null dereferences are often easy to detect at runtime, but other memory errors in systems programming are not solved by eliminating nil.
- Default zero-initialization can enable constant-time allocation patterns that explicit per-element initialization would make more expensive.
- Adopting strict compile-time memory-safety models (e.g., Rust, Ada) requires different programming idioms and can complicate low-level constructs like custom allocators.
Key facts
- Tony Hoare coined the phrase ‘billion dollar mistake’ for inventing null references in 1965; the author treats the monetary estimate as hyperbole.
- Null is typically represented as a zero sentinel in many platforms; modern systems reserve low virtual memory pages to help catch null dereferences.
- In garbage-collected languages, null tends to be the most common invalid address; in systems languages like C or Odin, other invalid addresses are often more common.
- Common non-null invalid-memory errors cited include use-after-free, incorrect pointer arithmetic, and unmapped memory regions.
- Odin intentionally keeps nil pointers and chooses implicit zero-initialization to remain a C-like alternative and to make the zero value useful by default.
- Avoiding nil by design requires either mandatory runtime checks for every pointer use or explicit initialization of every element at creation.
- Odin offers Maybe(^T) (a nullable/option type) and the author says it exists mainly for interfacing with non-Odin code or for non-pointer cases; he finds it seldom needed in typical systems tasks.
- The author believes C’s conflation of pointers and arrays contributes to many NULL-related problems and notes that Odin provides distinct, bounds-checked array types to address this.
What to watch next
- Whether projects with heavy low-level needs continue to prefer zero-initialization and implicit nil policies for performance and C-compatibility.
- Adoption and practical usage patterns of option/maybe types in systems-language ecosystems (the author says Odin’s Maybe(^T) is rarely needed).
- not confirmed in the source
Quick glossary
- Null pointer (nil/NULL/nullptr): A sentinel pointer value that indicates the pointer does not currently refer to a valid object; commonly represented as zero on many platforms.
- Maybe/Option type: A type that explicitly represents an optional value that may be present or absent, often used to avoid implicit nulls.
- Zero-initialization: Setting newly allocated memory to zero by default, which can make certain allocations effectively O(1) on platforms that zero pages automatically.
- Use-after-free: A memory safety bug where code continues to use a memory address after it has been freed or deallocated.
Reader FAQ
Did Tony Hoare really call null references a ‘billion dollar mistake’?
Yes; Tony Hoare described inventing null references as his ‘billion-dollar mistake,’ a quote the author cites and treats as hyperbolic rather than a literal estimate.
Are null dereferences the most common memory error in systems languages like C?
Not according to the author—he argues other invalid memory states (use-after-free, bad pointer arithmetic, unmapped memory) are often more prevalent in such languages.
Does Odin eliminate nil pointers entirely?
No. Odin retains nil pointers and opts for implicit zero-initialization to preserve C-like ergonomics; it also provides Maybe(^T) for optional values.
Would removing nil pointers everywhere be an obvious win?
The author contends it would not be an obvious win due to trade-offs like added programmer checks or forced explicit initialization that can hurt performance and architectural choices.
Was it really a Billion Dollar Mistake? 2026-01-02 TL;DR null pointer dereferences are empirically the easiest class of invalid memory addresses to catch at runtime, and are the least common…
Sources
- Was it a billion dollar mistake?
- Tony Hoare, null's creator, regrets its invention
- The Billion-Dollar Coding Mistake: Understanding Null …
- The Billion-Dollar Mistake: How Rust Solves Null …
Related posts
- Maybe Comments Should Explain ‘What’ — Rethinking Comments in Code
- How a Christmas beach moment with my partner changed Google Photos use
- Was It Really a Billion Dollar Mistake? Reassessing Null Pointer Costs and Trade-offs