Hacker News Reader

Comment by seles | Hacker News Reader

"Once you have constructors and you can statically ensure that every variable has a chance at initialization, you can start to escape one of the most unfortunate language misfeatures in wide use today: null"

Question, can anyone think of a case where the lack of pointers being able to point to null will make it more difficult to implement something? That is will you lose expressivity if this becomes impossible?

View on HN

The only case is when you want to express data is missing (not that a variable is unitialized, but that there's nothing there, think ternary boolean) and that is very neatly taken care of by option types (ML's `option`, Haskell's `Maybe`) which you can easily replicate via union types (create a type Nothing with a single value `nothing` and replace what was formerly a nullable type `T` by the union type `Nothing | T`; depending on whether you want these to be easy to use or not, you may or may not want to add the ability to lift computations into the option type)

Right. The language makes you check for nulls at the few places where the result can go null, and all other tedious null-checking goes away forever.

All the advanced type system jiggery-pokery aside -- that's probably the best "normal programmer" example of why ML & Haskell do static typing better. The ALGOL family of languages should have done that years (decades!) ago.

So many I wouldn't know where to start. Databases have had not-null constraints for years, but an accurate model often means having null values.

A better improvement would be to handle null references better - Rails' whiny_nil support is great for example.

> So many I wouldn't know where to start. Databases have had not-null constraints for years, but an accurate model often means having null values.

These nulls are a different issue than the initialization-originated nulls (that is in fact an other issue with null: they can mean both "I have nothing to put there" and "I forgot to put something there").

> A better improvement would be to handle null references better

No.

> Rails' whiny_nil support is great for example.

whiny_nil exists because you can't do much more in a dynamically typed language, apart from making nil a message sink. Go is not a dynamically typed language, and statically typed language communities have found much better ways to handle most cases where you would use null references decades ago.

Circular data structures where you need to simultaneously initialize two values to each other are the common case where this is problematic. To me, that's a fairly rare edge case and you can easily handle it using mutable variables and option or maybe types.

Reply on news.ycombinator.com