The fact that safe language implementations have to think hard about how to handle null pointer exceptions safely should have been a warning sign that null pointers are a bad thing to have in a language. Sadly nearly always unheeded.
-
-
Replying to @pcwalton @RichFelker
Are NPEs harder to handle safely, compared to other exception types?
2 replies 0 retweets 0 likes -
Replying to @ridiculous_fish @RichFelker
Yes. When you dereference a pointer you have to make sure that something safe happens if that pointer is null. It’s not as simple as making sure that the zero page is unmapped and catching SIGSEGV because you might overshoot the page if it’s e.g. an array.
2 replies 0 retweets 4 likes -
Replying to @pcwalton @RichFelker
Isn’t it as simple as emitting a null check at the point of dereference? That’s how Optional works after all.
2 replies 0 retweets 1 like -
Replying to @ridiculous_fish @RichFelker
That’s a *big* performance cost though. Not only in the cost of the actual test-and-branch, but also in the optimizations you inhibit.
2 replies 0 retweets 1 like -
Replying to @pcwalton @RichFelker
I think that argument works for Rust but not, say, Go. Nobody would notice if Go switched to emitting explicit null checks. Heck Swift *branches on all arithmetic* and that cost is not prohibitive within its domain.
2 replies 0 retweets 1 like -
Replying to @ridiculous_fish @RichFelker
1. I’m not sure nobody would notice. 2. To the extent that it wouldn’t be noticed, it’s because Go’s compiler generates slow code, somewhat hiding the problem. This doesn’t make it less of a problem. 3. Why go to all this trouble? Is null really so great that it’s worth it?
1 reply 0 retweets 2 likes -
The only thing null has going for it is that it’s “simple”. Except it’s really not. It’s arguably a simple interface (though I disagree that the interface is simple), but it’s not a simple implementation. Isn’t Unix/worse-is-better supposed to be about implementation simplicity?
2 replies 0 retweets 1 like -
Replying to @pcwalton @RichFelker
I didn't appreciate the implementation difficulties until now. Still, we would not add null even if tomorrow's hardware makes null checks free. So in my view the case against null is not really about performance or implementation difficulty.
1 reply 0 retweets 0 likes -
"We need to think hard about how to do X safely; that suggests X is bad" seems contrary to the spirit of Rust (and Swift and others). Haven't these languages been pioneers precisely through developers (such as yourself) thinking hard about how to do X safely?
1 reply 0 retweets 1 like
That’s not really contrary to the spirit of Rust. We’ve abandoned tons of things because of implementation difficulty: M:N threading for example.
-
-
Replying to @pcwalton @ridiculous_fish
M:N threading is just a bad model, and usually pursued a nasty workaround for bad OS characteristics, not because it's a programming model that makes sense.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Simplicity provides a much smaller surface area for implementation error, as well.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.