Null References: The Billion Dollar Mistake - Tony Hoare

What Hacker News said

Cites unlinked_dll · 2020-01 · on “A Reply to “Let’s stop copying C””

I believe that's a reference to Tony Hoare's famous talk about the invention of null references which he calls his billion dollar mistake [this video]

Cites benreesman · 2022-08 · on “C++ Concurrency Model on x86 for Dummies (2020)”

There's a constant tension between bit-packing and rich semantics older than me! As you likely know C.A.R. Hoare calls `null` his "billion-dollar mistake": [this video] . I linked the Cliff Click talk because it's the best example that I know about of someone using some semi-formal rigor around valid states and the transitions between them in the context of raw atomic operations to get a quite clearly correct result with a legitimate performance imperative: he had a machine with 768 cores, customers who bought that machine to have 768 threads jump on a hash table all at once and wanted ~~700x more throughput having paid for the machine. But even Cliff Click made sure that both his conceptual stat

Cites Ygg2 · 2025-08 · on “Partially Matching Zig Enums”

> Sure. With infinite energy, anything’s possible - we can prevent all bugs. The problem is, we don’t have infinite energy. You don't need infinite energy but it is a significant undertaking. The UB seem to obey a power law in regards to their lifetime i.e. every X years number of UB caused problems halves. > I can only recall one serious concurrency bug I’ve ever had (a data race) which took some debugging time to track down, but it wasn’t in Go. YMMV. That's what is nasty about UB in data races. It's not trivial to find and it's a pain in the neck to reproduce. So even taking you at your word, you not having issues with data races isn't the same as "I wrote code free of data races". > As f

Cites lossolo · 2025-08 · on “Partially Matching Zig Enums”

> Even without a chance of UB. You're adding an implicit `Type | null` to every piece that uses nullable code without handling the null case. Each time you forget to do it, you cause either an UB or a null pointer error. And the place it manifests is different from where it's generated. > Furthermore, listening to Tony Hoare's talk ( [this video] ), he mentions that trying to avoid the null, in the context of a language like Java or C#, that permits them is also causing people to waste time working around them. It's an insignificant amount of time in my experience, which makes this irrelevant in practice. I’ve never had to "work around them", this is either a theoretical argument or just sloppy p