Null References: The Billion Dollar Mistake

#1

Post by wheresvic3 » Sat, Jan 11, 2020, 12:55 PM UTC

Null References: The Billion Dollar Mistake
infoq.com

Re: Null References: The Billion Dollar Mistake

#2

Post by seventh-chord » Sat, Jan 11, 2020, 1:34 PM UTC

"Making everything a reference: The Billion Dollar Mistake" is the talk I want to see

Re: Null References: The Billion Dollar Mistake

#3

Post by x3ro » Sat, Jan 11, 2020, 1:36 PM UTC

This comes up again and again in one form or the other, yet new languages still seem to be making the same mistake. Of all languages I've touched, Rust seems to be the only one that mostly circumvents this problem. Are there other good examples?

Re: Null References: The Billion Dollar Mistake

#4

Post by x3ro » Sat, Jan 11, 2020, 1:38 PM UTC

seventh-chord wrote: post #2

"Making everything a reference: The Billion Dollar Mistake" is the talk I want to see

Can you elaborate? I can't remember the last time I thought "oh darn it why is this a reference", but I can think of a billion problems I've had with nulls in jvm languages

Re: Null References: The Billion Dollar Mistake

#5

Post by gameswithgo » Sat, Jan 11, 2020, 1:38 PM UTC

x3ro wrote: post #3

This comes up again and again in one form or the other, yet new languages still seem to be making the same mistake. Of all languages I've touched, Rust seems to be the only one that mostly circumvents this problem. Are there other good examples?

rust, f#, ocaml, latest version of c# has an option to sort of get rid of nulls, zig

Re: Null References: The Billion Dollar Mistake

#6

Post by gameswithgo » Sat, Jan 11, 2020, 1:39 PM UTC

seventh-chord wrote: post #2

"Making everything a reference: The Billion Dollar Mistake" is the talk I want to see

there are a few completely different ways to interpret this, can you explain?

Re: Null References: The Billion Dollar Mistake

#7

Post by emsy » Sat, Jan 11, 2020, 1:43 PM UTC

x3ro wrote: post #4

seventh-chord wrote: post #2

"Making everything a reference: The Billion Dollar Mistake" is the talk I want to see

Can you elaborate? I can't remember the last time I thought "oh darn it why is this a reference", but I can think of a billion problems I've had with nulls in jvm languages

Cache incoherency, which will cost us more and more performance as CPUs will improve slower in the future.

Re: Null References: The Billion Dollar Mistake

#8

Post by hawkice » Sat, Jan 11, 2020, 1:44 PM UTC

x3ro wrote: post #3

This comes up again and again in one form or the other, yet new languages still seem to be making the same mistake. Of all languages I've touched, Rust seems to be the only one that mostly circumvents this problem. Are there other good examples?

Haskell, notoriously. I believe it pioneered the ergonomics of the alternatives used elsewhere.

Re: Null References: The Billion Dollar Mistake

#9

Post by jrockway » Sat, Jan 11, 2020, 1:49 PM UTC

x3ro wrote: post #3

This comes up again and again in one form or the other, yet new languages still seem to be making the same mistake. Of all languages I've touched, Rust seems to be the only one that mostly circumvents this problem. Are there other good examples?

I assume two reasons, efficiency and because an efficient implementation of mutable state would have the same problem.

Right now, a single sentinel value makes a pointer null or not null (0x0 is null, everything else is not null). This is exactly how you'd implement a stricter type, like "Maybe". Encoded as a 64-bit integer, "Nothing" would be represented as 0x00000000 and "Just foo" would be represented as 0xfoo. No object may be stored at the sentinel value, 0x00000000. Exactly the same as what we have now, and provides no assurances that 0xfoo is actually a valid object.

Meanwhile, Haskell which "doesn't have null" crashes for exactly the same reason your non-Haskell program crashes with a null pointer exception:

    f :: Num a => Maybe a -> Maybe a
    f (Just x) = Just (x + 41)

This blows up at runtime when you call f Nothing, because f Nothing is defined as "bottom", which crashes the program when evaluated.

It's exactly the same as langages with null pointers:

    func f(x *int) *int {
        result := *x + 41
        return &result
    }

And the solution is the same, your linter or whatever has to tell you "hey maybe you should implement the Nothing case" or "hey maybe you should check the null pointer".

Where I'm going with this is that you need to develop entirely new datatypes and have an even stricter type system than Haskell. Maybe Rust is doing this, but it's hard. We all know null is a problem, but calling null something else doesn't make the problems go away.

Re: Null References: The Billion Dollar Mistake

#10

Post by deepaksurti » Sat, Jan 11, 2020, 1:51 PM UTC

x3ro wrote: post #3

This comes up again and again in one form or the other, yet new languages still seem to be making the same mistake. Of all languages I've touched, Rust seems to be the only one that mostly circumvents this problem. Are there other good examples?

Swift with optional and optional chaining. [1]

[1] https://docs.swift.org/swift-book/LanguageGuide/OptionalChai...