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

81–90 of 158 posts

Re: Null References: The Billion Dollar Mistake

#81

Post by empath75 »

zozbot234 wrote: post #41
amelius wrote: post #34

Earlier quoted context omitted.

Imho, Rust is an awkward language because it positions itself as a systems language but it makes low-level stuff more difficult (there's even a book teaching how to implement doubly linked lists in Rust [1]), hence prone to mistakes. At the same time, people are using Rust to build non-systems programs, where other languages would be more appropriate (e.g. those with garbage collectors). I don't think it is a good id…

> 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…

I’m a rust fan, but garbage collection is about removing having to think about memory management from the developer almost entirely, not about performance.

Re: Null References: The Billion Dollar Mistake

#83

Post by bitwize »

empath75 wrote: post #81
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…

I’m a rust fan, but garbage collection is about removing having to think about memory management from the developer almost entirely, not about performance.

Value and move semantics do the same thing and work in 90% of the cases a GC does. For the remainder there's ARC.

Re: Null References: The Billion Dollar Mistake

#84

Post by reificator »

fhars wrote: post #53
agumonkey wrote: post #44

Earlier quoted context omitted.

But for numbers, a zero is not considered null, because it was handled in the operators rules.

Numerical zero has nothing to do with the issue discussed here. What you are proposing is to add another “number” to types like int and float that results in the program crashing whenever you try to add it to another number.

> What you are proposing is to add another “number” to types like int and float that results in the program crashing whenever you try to add it to another number.

There's already division by zero and NaN to trip you up in IEEE754.

Re: Null References: The Billion Dollar Mistake

#86

Post by goatlover »

fhars wrote: post #53
agumonkey wrote: post #44

Earlier quoted context omitted.

But for numbers, a zero is not considered null, because it was handled in the operators rules.

Numerical zero has nothing to do with the issue discussed here. What you are proposing is to add another “number” to types like int and float that results in the program crashing whenever you try to add it to another number.

Or there's NaN which just results in NaN and doesn't equal itself. No need to crash.

Re: Null References: The Billion Dollar Mistake

#87

Post by tsimionescu »

kerkeslager wrote: post #24
rzwitserloot wrote: post #11

This old chestnut again. There is an inherent problem in designing processes and writing code to capture them: The notion of not-a-value. There are great many ways to solve them. The most common ones are 'null' and 'Optional[T]'. Neither just makes the problem magically go away. If a process is designed (or a programmer writes it) thinking that 'ah, well, here, not-a-value cannot happen', but it can, then.. you have…

> There are great many ways to solve them. The most common ones are 'null' and 'Optional[T]'. Neither just makes the problem magically go away. If a process is designed (or a programmer writes it) thinking that 'ah, well, here, not-a-value cannot happen', but it can, then.. you have a bug. > Some language features might make it possible to help reduce how often it occurs, but eliminate it? I don't think so. On the co…

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 => {return arr[someInt]}, 
        () => { /*never happens*/ return 0; })
(using a slightly simpler notation that your version, since I'm on mobile)

Now, if you were wrong and you do get a Nothing, instead of seeing a nice stack trace, you have an absurd 0 running forward. You could improve this using an assert() but this is what managed languages already do with the NullPointerException&friends.

The more interesting thing to show is all the code that does not deal with optional and that is now magically free of any possibility of null errors. But the programmer is still responsible for correctly treating the moment they need to go from optional values to non-optional, and here Optional is essentially just more in-your-face than null (which is valuable, don't get me wrong).

The only example I know of where a language feature truly completely eliminates a category of errors is managed memory, which does not replace memory errors with any other more-or-less equivalent error case.

I personally very much doubt NULL is a significant source of errors in managed memory languages. It's not nothing, but they are some of the easiest bugs to track down.

Re: Null References: The Billion Dollar Mistake

#88

Post by empath75 »

bitwize wrote: post #83
empath75 wrote: post #81

Earlier quoted context omitted.

I’m a rust fan, but garbage collection is about removing having to think about memory management from the developer almost entirely, not about performance.

Value and move semantics do the same thing and work in 90% of the cases a GC does. For the remainder there's ARC.

If you think rust eliminates the need to think about it in the way that python does, I don’t know what to tell you.

Re: Null References: The Billion Dollar Mistake

#89

Post by nielsbot »

samatman wrote: post #74
kragen wrote: post #69

Earlier quoted context omitted.

If we're limiting ourselves only to new languages, then nulls are statically excluded not only by Kotlin and Apple’s imitation of it, Swift, but also by F#, Agda, Idris, Elm, and (sort of) Scala. But the zozbot didn't seem to be talking only about new languages, so Haskell, Miranda, Clean, ML, SML, Caml, Caml-Light, and OCaml are also fair game. (It wouldn't be hard to list another dozen in that vein.) Moreover I thi…

Good list. I've found the consequences of a nil type are less severe in dynamic languages, where all variables have the Any type, since nil is just one of the options one needs to account for. Static languages where everything is nullable are reneging on the promise; you say something is a String but that just means Option , and it saps a lot of the reasoning power which static typing should give.

`let s:String` is not the same as `let s:String?` in Swift, at least. (Nor in TypeScript)

Re: Null References: The Billion Dollar Mistake

#90

Post by int_19h »

Matthias247 wrote: post #77

Out of all possible gotchas in programming languages I still find null pointers the easiest one to discover and fix. You directly see when and where it happens, and the fix is usally straightforward. Compared to that invalid pointers (stale references) are a lot more painful, since programs might continue to work for a while. Managed languages do at least prevent those. Multithreading issues are imho the biggest pain…

You directly see where the null dereference happens. But that's not necessarily where the problem actually is, because a null pointer can flow through a lot of code before it actually gets dereferenced. So "program continues to work for a while" is also a thing with them.

In a language like C, a null pointer can also become an invalid non-null pointer pretty easy with pointer arithmetics.

Post reply on HN