Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Null References: The Billion Dollar Mistake

infoq.com

Post reply on HN
Print view View original

121–130 of 158 posts

Re: Null References: The Billion Dollar Mistake

#121

Post by Stratoscope »

amelius wrote: post #117
Stratoscope wrote: post #115

Earlier quoted context omitted.

> ...Andrei Alexandrescu was right when he said Rust feels like it "skipped leg day" (in the sense that it has its party piece and not much else) - from the perspective of the arch metaprogrammer himself at least. Mind if I ask what that means? It seems like an interesting observation, but there are a couple of bits of terminology I don’t understand, like "leg day" and "party piece". Any clarification would be apprec…

Perhaps this link would explain it more clearly: [1]. Leg-day is bodybuilding terminology, and refers to the day of the week when the bodybuilder is supposed to be training the leg muscles. According to the meme, nobody wants to train the legs because they show the least. [1] https://www.jonathanturner.org/2016/01/rust-and-blub-paradox...

Thank you, that is very informative!

> nobody wants to train the legs because they show the least.

It reminds me of the story about how Google drops products because no one wants to maintain an existing product. That would not show "impact", not like launching a new product would, and impact is how you get raises and promotions.

Re: Null References: The Billion Dollar Mistake

#122

Post by jayd16 »

amelius wrote: post #116
zozbot234 wrote: post #41

Earlier quoted context omitted.

> there's even a book teaching how to implement doubly linked lists in Rust [1] Doubly-linked lists are an awkward example because the "safety" of a doubly-linked list as a data structure involves fairly complex invariants that Rust can't even keep track of at this point, much less check independently. These things are exactly why the unsafe{} escape-hatch exists and is actively supported. But just looking at the amo…

> Doubly-linked lists are an awkward example because the "safety" of a doubly-linked list as a data structure involves fairly complex invariants that Rust can't even keep track of at this point. Perhaps it's just me, but I'd like to assume that my language does not treat any algorithm found in a basic algorithms course (e.g. Sedgewick) as awkward.

Eh, I have no problem with the idea that data structures that work in C are awkward in different paradigms. Many data structures are awkward in functional programming. Lots of things are awkward in C that are easier in other languages.

Re: Null References: The Billion Dollar Mistake

#123

Post by dpbriggs »

amelius wrote: post #116
zozbot234 wrote: post #41

Earlier quoted context omitted.

> there's even a book teaching how to implement doubly linked lists in Rust [1] Doubly-linked lists are an awkward example because the "safety" of a doubly-linked list as a data structure involves fairly complex invariants that Rust can't even keep track of at this point, much less check independently. These things are exactly why the unsafe{} escape-hatch exists and is actively supported. But just looking at the amo…

> Doubly-linked lists are an awkward example because the "safety" of a doubly-linked list as a data structure involves fairly complex invariants that Rust can't even keep track of at this point. Perhaps it's just me, but I'd like to assume that my language does not treat any algorithm found in a basic algorithms course (e.g. Sedgewick) as awkward.

For sure, you can avoid awkwardness by not statically verifying memory usage & invariants (c++, etc) or using a GC'd language. Rust's ownership and borrowing rules are limited, but simple enough for someone to internalize them quickly.

There's a pretty vast difference between human simple and computer simple. Rust requires that you prove memory safety, or use unsafe. That's a different problem than just informally ensuring invariants are met.

You could probably pull in more advanced type theory research for more nuanced ownership, but I'd bet the language would be harder to understand overall (Haskell disease).

Re: Null References: The Billion Dollar Mistake

#124

Post by zozbot234 »

jayd16 wrote: post #120
zozbot234 wrote: post #41

Earlier quoted context omitted.

> there's even a book teaching how to implement doubly linked lists in Rust [1] Doubly-linked lists are an awkward example because the "safety" of a doubly-linked list as a data structure involves fairly complex invariants that Rust can't even keep track of at this point, much less check independently. These things are exactly why the unsafe{} escape-hatch exists and is actively supported. But just looking at the amo…

GCs are also good at compacting heaps.

Perhaps, but at pretty severe cost. Your heap must be structured in a way that the tracing routine can make sense of (and the consequences of this involve considerable waste and inefficiency in practice - lots and lots of gratuitous pointer chasing), and the compacting step itself involves a lot of traffic on the memory bus that trashes your caches and hogs precious memory bandwidth.

Forget it. Obligate GC is a terrible idea unless you really, really, really know what you're doing.

Re: Null References: The Billion Dollar Mistake

#125

Post by [deleted] »

DaiPlusPlus wrote: post #17
seventh-chord wrote: post #15

Earlier quoted context omitted.

in languages like c, rust or go, where you can put arbitrary data on the stack, it seems to me as if such issues are less common because you dont have to worry about initializing pointers and allocating memory unless you actually want to put something on the heap. Thus if you make everything a reference in your language its no wonder you run into issues like null-pointers more often

With stack allocation you then encounter problems with object lifetime. Rust solves this problem by binding references to scope, and Go solves this by invisibility changing an allocation to the heap (and uses ref-counting? I think?). I wish C had a feature that would let you allocate something on the stack and then return to the parent stack frame without popping the stack-pointer - that would be handy for self-conta…

[deleted]

Re: Null References: The Billion Dollar Mistake

#126

Post by jayd16 »

DaiPlusPlus wrote: post #17
seventh-chord wrote: post #15

Earlier quoted context omitted.

in languages like c, rust or go, where you can put arbitrary data on the stack, it seems to me as if such issues are less common because you dont have to worry about initializing pointers and allocating memory unless you actually want to put something on the heap. Thus if you make everything a reference in your language its no wonder you run into issues like null-pointers more often

With stack allocation you then encounter problems with object lifetime. Rust solves this problem by binding references to scope, and Go solves this by invisibility changing an allocation to the heap (and uses ref-counting? I think?). I wish C had a feature that would let you allocate something on the stack and then return to the parent stack frame without popping the stack-pointer - that would be handy for self-conta…

Isn't that just how return values work or did I woosh a joke?

Re: Null References: The Billion Dollar Mistake

#127

Post by throwaway2048 »

int_19h wrote: post #91
microcolonel wrote: post #85

Null references are not a mistake, they make perfect sense. Letting nullable types be dereferenced directly is the mistake. Null references are at the core of a great number of sensible datastructures, and they're a natural fit for conventional computers.

There are two separate concepts here that often gets conflated. There's null reference in a sense of a special pointer value (usually all bits set to 0) that means "this doesn't point to anything". That's a useful low-level tool that allows for compact representation of many important data structure. And then there's null reference in a sense of type systems. To be more specific, "null reference" here is really a sho…

To put it a bit more compactly, why is Boolean logic "True, False, Null"

Re: Null References: The Billion Dollar Mistake

#128

Post by _bxg1 »

samatman wrote: post #67
zozbot234 wrote: post #12

Earlier quoted context omitted.

> Rust seems to be the only one that mostly circumvents this problem. The Rust hype is getting ridiculous here. There are plenty of languages with non-nullable references as first-class, and optionals for the nullable case. (...And I say this as a Rust fan myself, for what it's worth.)

This comment would be much improved with a list of those languages. Kotlin and Swift come to mind, what are others?

TypeScript/Flow

Re: Null References: The Billion Dollar Mistake

#129

Post by dorfsmay »

brudgers wrote: post #55
dorfsmay wrote: post #14

Earlier quoted context omitted.

Everything in Python is a reference, and there's no null pointer issues.

Everything in Python is an object. In Python, containers are objects that reference other objects. https://docs.python.org/3/reference/datamodel.html https://docs.python.org/2.0/ref/objects.html

How are name bindings different than references?

    >>> a=[2, 3, 1]
    >>> b=a
    >>> id(a)
    139731931982216
    >>> id(b)
    139731931982216
    >>> b
    [2, 3, 1]
    >>> b.sort()
    >>> del(b)
    >>> a
    [1, 2, 3]
    >>>

Re: Null References: The Billion Dollar Mistake

#130

Post by tsimionescu »

kerkeslager wrote: post #95
tsimionescu wrote: post #87

Earlier quoted context omitted.

The problem GP was raising is on the other half of Optional: when you do finally need an int. Say, you want to do arr[*increment(maybeInt)] //error: can't dereference Optional Now, if you as a programmer don't think increment(maybeInt) can actually return None in your particular case, you will probably do the minimal work to convince the compiler to let it go, say matchOptional( increment(maybeInt), someInt => {retur…

If it really can't ever be null, then it should just be an int, not an Optional . The entire reason that it is an Optional is that it CAN be null. In this hypothetical language, not initializing an int is a compiler error, assigning null to an int is a compiler error, etc. If it's an int it literally cannot be null. What ends up happening in practice is that the null is handled close to where it's created, and the re…

There are normal cases where this can happen. For example, a map should normally return an Optional when you try to retrieve a key's association. However, there may be special cases where you know that a key is present (maybe it is a constant map, maybe you just set the value of that key etc).

I do agree that these cases are much rarer than the cases where a value is either always there, or the cases where a value really can be missing. I was only pointing out that Optional doesn't eliminate 100% of null errors, just 99.9% of them.

Post reply on HN