News for hackers. Stuff that matters.
Re:Null References: The Billion Dollar Mistake by kragen on Saturday January 11, 2020 @05:41PM (#22022890)
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 think you could sort of make a case for languages like Prolog and Aardappel where you don't have a static type system at all, much less one that could potentially rule out nils, but in which the consequences of an unexpected nil can be much less severe than in traditional imperative and functional languages like Java, Lua, Python, Clojure, Smalltalk, or Erlang, which more or less need to crash or viralize the nil in those cases.
Re:Null References: The Billion Dollar Mistake by samatman on Saturday January 11, 2020 @06:08PM (#22023053)
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<String>, and it saps a lot of the reasoning power which static typing should give.

Re:Null References: The Billion Dollar Mistake by philwelch on Saturday January 11, 2020 @10:21PM (#22024246)
Even in dynamic languages, the consequences can be pretty bad. For example, I've seen lots of Ruby bugs where things end up being unexpectedly `nil`, but I haven't seen as many Python bugs where things end up being unexpectedly `None`.

How does this happen? Well, in Ruby it's a lot more normal to just return nil. For example, consider the following code snippet:

  [][0]
In both languages you are trying to examine the zeroth element of an empty array (or list, as Python calls it). In Ruby this evaluates to nil. Python throws an IndexError. So in Python, if you have a bug where you address an array with an invalid index, it manifests as an error in how you're indexing the list. Ruby silently returns nil, and the only actual error backtraces you see are when you actually try to call a method on this nil later on, which might not be anywhere near where your program messed up the array indexing.
Re:Null References: The Billion Dollar Mistake by perl4ever on Wednesday January 15, 2020 @01:02AM (#22052066)
That seems (although I don't have experience with either language) straightforwardly correct treatment in Python and wrong in Ruby, and the problem seemingly should be attributed to [lack of] range checking, not nil/null.
Re:Null References: The Billion Dollar Mistake by philwelch on Wednesday January 15, 2020 @01:47PM (#22057098)
Sure; in this case, range checking provides an alternative behavior to generating a null reference. But Ruby has other places where it generates null references more promiscuously than Python. Java does too. If you take every use case that could generate a null reference and instead behave differently in that situation you’ve eliminated null references, and Python has largely done so despite having a None type.
Re:Null References: The Billion Dollar Mistake by nielsbot on Saturday January 11, 2020 @07:09PM (#22023393)
`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 by kragen on Saturday January 11, 2020 @08:16PM (#22023727)
Right, that's why Swift is in the lists above. TypeScript would've been a good addition, I just didn't think of it.
Re:Null References: The Billion Dollar Mistake by kragen on Saturday January 11, 2020 @06:17PM (#22023112)
Concur.