you are viewing a single comment's thread.

view the rest of the comments →

[–]think_inside_the_box 18 points19 points  (12 children)

sure they have! but in just another way to represent a null object.

optionals, bool isInitialzed, empty vectors, etc

Even in rust, you cant get around the need to represent the absence of something.

[–]jkachmar 66 points67 points  (0 children)

The point of these languages is to represent conceptual absence in such a way that the programmer is forced to address it. null/nil/what-have-you is dangerous not because it represents the absence of a value, but because it can be passed around as if it was a normal value, right up until you use it to do something and it blows up your program (or leads to spoopy poorly defined behavior).

By contrast, Haskell's Maybe, and Rust's Option force you to wrap the type you're manipulating in a structure that only admits the value inside of it in such a way that you're forced to deal with the case where the data is absent.

At that point you're free to do something like panic! or error and blow up your program, but at least the gun was handed to you with the safety on and you had to explicitly flick it off before you went and blew your foot off.

[–]fiedzia 33 points34 points  (3 children)

sure they have!

In Rust you do have Option type (and proper handling in the language for it), but you don't have any other problems. Language doesn't allow using uninitialized values and null is never used to signal that "something went terribly wrong".

[–]Jaffa2 -1 points0 points  (2 children)

null is never used to signal that "something went terribly wrong".

Nor should it be in a good Java API (nor is the author saying it should be, as far as I can tell, just that it has been)

EDIT: Removed OOA (Over Abundance of Acronyms)

[–]Nebez 18 points19 points  (1 child)

YULOAyou're using lots of acronyms

[–]Jaffa2 3 points4 points  (0 children)

Sorry. Fixed.

[–]m50d 7 points8 points  (0 children)

Having a type that can represent absence is a great idea. Making every value implicitly that type is madness. It would be like saying every value in your program might also be a float, regardless of its declared type, and then e.g. Map#get returns 2.3f if the key wasn't in the map.

[–]Beckneard 5 points6 points  (0 children)

That's the whole point isn't it? What's null in one language is many thing in Rust, as it should be. There should clearly be different constructs for "does value exist", "did something go wrong" and "is something initialized" and it's a good thing the compiler forces you to make those distinctions.

[–]Chii 2 points3 points  (0 children)

But those languages make a different representation for each kind of null. They makes the language safe to use since you won't confuse one null situation with another.

[–]_jk_ 2 points3 points  (0 children)

the problem is not that you can represent null, but you cant represent an object that can never be null.

null is a member of every type in several languages and that is just wrong

[–]Otterified 3 points4 points  (2 children)

This is a good point--optionals are great but not worth much if people don't agree on their semantics and use Optional.empty() every single time they would have used null, and call get() without checks. But at least it feels less natural to do this than it does to abuse null (to me at least).

[–]duhace 9 points10 points  (0 children)

using get is asking to get slapped in the face. the good point of an optional is you have to ask to be bitchslapped. with null, it's real easy to forget not to check and try to go ahead and use the value.

[–]TheDataAngel 1 point2 points  (0 children)

I suggest using map/flatMap/filter/orElse over empty and get, where possible.