1. It's hard to support circular data structures in an imperative language without null pointers.

2. Restricting a language to non-circular data structures will not be popular.

3. Having a nullable and non-nullable version of every pointer or reference type is not usually super popular either.

Phrased differently: nullable types are actually a fairly reasonable compromise from a set of not fully appealing choices.

Circular data types are perfectly fine with optional types. You can have optional<*raw_pointer> for example which after compilation may even be equivalent to a simple null, since valid pointers are not-null.

This was discussed in rust some time ago: https://mail.mozilla.org/pipermail/rust-dev/2013-March/00330...

Having nullable and non-nullable versions of every type is fine if you have decent syntax for it. Take Kotlin for example:

https://kotlinlang.org/docs/reference/null-safety.html

You also need type polymorphism (which Java and most of the languages under discussion did not have/did not start with), or it will drive you crazy.

And you may start needing fancier versions of polymorphism to express things like "this accepts a T=Foo or Optional<Foo>, and returns Bar<T>".

In passing, I remain to be convinced that that x?.length/etc syntax (and equivalents in other variations of Optional) is really a good idea - to me, it feels like an error-prone way of papering over the fact that non-explicit null(aka absent-optional) checks are just too painful to program with. Phrased differently, I see no reason to believe that the sufficiently-common-to-warrant-special-support appropriate handling of null is just to feed it up through as the computation of the computation if it occurs in any part.

Well, not really. What Kotlin has is exactly an Optional type. It's just a different syntax for it.

There's one difference between nullable/non-nullable types and Optional type, which is nesting, right?

I'd assume that while Kotlin's String? is equivalent to Optional<String>, Kotlin has no equivalent to Optional<Optional<String>>.

Which, personally, I think I'd prefer Kotlin's approach, because that means you can do `maybeString = "exists"`, which is more readable than `maybeString = Optional::Exists("exists")`

Sure. In Haskell you join them, but just not allowing it perhaps better.

Also, you can still nest them in Kotlin, since you can have a nullable type inside generics.

Interesting, I haven't heard this argument before. So what is it about null that makes it more feasible here than for example option types/tagged unions?

Also, regarding your third point, IMO the question mark syntax in for example TypeScript and C# is fine.

Way back when when the JVM/CLR were being originally designed, I'm not sure that Option types as a concept were quite as proven, and both languages were trying to be "safe" languages that didn't have any complicated or new concepts in them. Optional types might not be that now, but they probably were then, when they were strictly in the domain of fairly academic languages.

I'm not entirely sure where or when it was introduced, the first mention of it I could find was May 1989 (pg 25)

ftp://ftp.cs.princeton.edu/reports/1989/220.pdf

Destroying a language's safety for a single use case is a terrible trade-off.

There are various possible solutions for circular structures that do not require destroying all static safety with nulls everywhere.

Do people keeping doing that? All the new languages I see seem to embrace optional.

Go is one of the worst/weirdest. It has semantics around uninitialized variables that most programs will rely on for correctness. And it also has nil.

And nils in Go might be different. That's even more weird.

Right, interface Nils compare on type too, right? This is bananas.

Go is bad in that it uses pointers to make something nullable, but i dont think the uninitialised non nullable values are zero is that bad. Otherwise uninitialised is another type of null...

  Doing so *nullifies*

pun intended?

I use dynamically typed languages the majority of the time, i never really saw the advantage of static typing. I do however rely on the database for typing quite heavily.

I also usually prefer dynamic typing. When I do use languages with static typing, I really want the compiler to be able to tell me that `foo` is definitely an Int and not Null.

c# has an option type. You can make any struct type nullable with a ?.

The issue is you can't make reference types non-nullable (yet, they're working towards that end for 8.0).

Those interested in how C# 8.0 approaches the problem might appreciate Mads Torgersen's thoughts on the matter [0] (relevant part starts at 5:40).

[0] https://channel9.msdn.com/Blogs/Seth-Juarez/A-Preview-of-C-8...

Do you know how they're solving the problem of the language expecting a `default(T)` to exist for every type?

You can get a pretty complete overview at https://blogs.msdn.microsoft.com/dotnet/2017/11/15/nullable-...

But essentially they're not solving it: you will get a warning on explicit default-ing of a non-nullable reference, you will get a warning on implicitly initialising/defaulting class fields, but you will not get warnings when doing so for structs or arrays.

Thanks. That looks quite interesting.