Why nullable types?

For anyone interested, there's also an excellent article on how nullable types work in Dart, that's more of a deep dive:

https://dart.dev/null-safety/understanding-null-safety

I agree that union-typed null was the best solution for Dart, but I think many of the article's criticisms of option types aren't good.

> We can’t perform arithmetic on an Option any more than we could on a List.

Why not? One sensible definition is

    Some(x) + Some(y) = Some(x + y)
    _       + _       = None()

> In fact, with Dart, we’ve found that most existing code is already statically null safe

This is a very good reason to use union types — lots of programs and lots of people are used to thinking this way, and pulling that out from under their feet wouldn't be very nice.

> Nullable types, since they have no explicit runtime representation, are implicitly flattened.

Yes, flattening things that shouldn't be flattened is the biggest problem with union types. Different people will assign different meanings to null, and it's a real headache when trying to write generic code. Discriminated unions make this a no-brainer.

> With nullable types, since there is no representation difference, you can pass a value of the underlying type directly: takesMaybeInt(3);

That's a very minor difference, but if it's that important, Rust lets you write

    fn takesMaybeInt(x: impl Into>) { ... }

Me and my team prefer Option to nullable types. Option is much more clear and idiomatic FP than nullable types.

Granted, Option.map and flatMap and nullable type ?.let{} are functionally equivalent but the former just reads so much better, and we want not just functor and monad but applicative as well, no?

Eg given a List, we can use applicative to declaratively and with referential transparency etc etc (you know the usual FP sales pitch) turn it into an empty list if it contains a single non-populated option, or a list of Foo if all options in the list are populated.

With nullable types I don't think you could do it as declaratively and elegantly.

Actually, even if you could, it's kind of beside the point...

To me, the point is, Option has been designed from scratch to be an FP style Maybe type with all that comes with that in terms of it being a functor, applicative functor, monad etc etc whereas while nullable types in some ways are functionally equivalent, a nullable type doesn't implement a Functor interface, or a Monad interface, or an Applicative interface, and when it behaves like it does, it's mostly kind of by accident driven by a pragmatic need, not any real understanding of reusable, lawful FP abstractions.

Nullable type is the biggest mistake in all the "modern" languages

It should be a type Optional, not built into a language, it make no sense memory wise

It's like NULL, it should stay, it is not an issue, it is how computers work!!!!!!!

This comment is misleading. They may appear to be the same but they are not because in certain languages (like Rust) you are forced to handle the `Option` case when a value is `None` which guides a programmer's thinking in the direction of what to do in that situation.

Without these higher level types runtime null pointer exceptions are very common, using `Option` or `Maybe` creates a situation where these sorts of errors are a lot less likely.