Hacker News Reader

Comment by PaulAJ | Hacker News Reader

This mistake is fixed in Haskell.

Rust, too!

Edit: Btw, I disagree with how the article categorizes Rust in comparison to Haskell. It shows that Rust has std::ptr::null, but neglects the fact that Haskell has Foreign.Ptr.nullPtr. Either both should be "5 stars" or both should be "4 stars".

Ya, all of the 4 star ones basically include it in their ffi compatibility layers. The five star ones do too.

Came here to say this. In fact, I think every language that they give 5 stars to has some form of "foreign pointer", "raw pointer", "unsafe pointer" or the like that is nullable, for FFI and other low level tasks.

I think that anything which has no null in normal, idiomatic code, outside of "unsafe", "ffi", or similar subsets, should get 5 stars. The distinction is really about whether you need to worry about any possible value, or any possible reference, being null, which you do in languages like C or Java where all references are nullable.

Giving Java and Rust the same 4 star rating because they both have some form of null and some form of Maybe/Option is a bit misleading. In Rust, Option is what you use in any normal code, and so you don't need to check for Null everywhere. In Java, it's the other way around; nullable references have existed since the beginning and are not segregated in any particular way, while Optional is a recent addition.

Likewise, I think that in Scala and Swift, null is only present for compatibility purposes, and idiomatic code does not use them. I'm not sure about F#. Clojure does use nil idiomatically, and also has '(), which may even count as "multiple NULLs" according to this rubric, though I guess that in Clojure '() is just treated as an empty list, rather than a null value like it is in other Lisps.

> Likewise, I think that in Scala and Swift, null is only present for compatibility purposes, and idiomatic code does not use them. I'm not sure about F#.

I believe though that with the exception of Swift, null can infect these language's quite easily via the FFI, and the guarantees aren't as strong. I haven't used them much though, so I could be wrong.

Yeah, I guess it depends on how often you use the FFI, and I'm not familiar enough with these languages in practice to know how often that comes up. Part of the point of each of these is that they can utilize an existing ecosystem in which null is common (Java/JVM for Scala, C#/CLR for F#, Objective-C/Cocoa for Swift).

I know that in practice in Rust, the general approach is to write safe wrapper around any C libraries you're using, so the use of nullable pointers is generally confined to those wrappers.

Author here. I didn't know that about Haskell.

Admittedly, the "rating" is pretty rough, maybe even a bad idea.

I've seen std::ptr::null more than I ever have Foreign.Ptr.nullPtr.

But really, both are usually used for compatibility with external libraries/programs/runtimes, not for idiomatic language programming.

Both great languages in my book :)

> I've seen std::ptr::null more than I ever have Foreign.Ptr.nullPtr.

Probably because we need to work with the C API a great deal right now, but that should change as more and more things are written in Rust. Still, the unsafe boundary helps by removing the ability to dereference a raw pointer in safe code - something that Haskell doesn't have.

FYI, I fixed it. std::ptr::null isn't really comparable, so I removed it. You can't really use it in Rust like you could in other languages.

https://hackage.haskell.org/package/base-4.8.1.0/docs/Foreig...

The star chart at the end of the article lists Haskell, OCaml, and Standard ML as languages that omit NULL. (Where no null means five stars, of course.)

I think Rust should also have 5 stars in this comparison as it forbids null pointers.

That's mentioned in the article. It gives Haskell's null handling a score of 5 stars, along with OCaml and Standard ML.

EDIT: The articles definition of 5 star null handling is "Does not have NULL." :)

Not completely. non-nullable by default is nice, ignoring possible nulls is nice, but Haskell's Maybe still suffers from premature generality by conflating all forms of absence. A 'Maybe T' is fundamentally, context-sensitively, not equivalent to any other 'Maybe T' in the same way all 'T's are. This is bad.

edit: carsongross beat me to what I'm talking about with a better explanation: https://news.ycombinator.com/item?id=10149129

When you need to distinguish missing values, that's why Haskell has Either. Maybe is for when you only care if there is a good result are not, Either covers the case when you need to distinguish different kinds of "not".

Can't you just handle this with something like `Either ErrCode T`?

(And if not, please do explain why!)

You can, but the existence (and use in libraries!) of Maybe is still bad for the same reason having 'null' is bad. It's an anti-feature that would enrich the language by not existing.

Haskell has `undefined` bombs, which are a similar problem.

Reply on news.ycombinator.com