I find it weird that people keep making languages with static typing where all types can also be null instead of using an option type. Doing so nullifies a significant amount of the correctness checking static typing provides.
It makes some sense for interoperation when living inside .NET or the JVM, but this was a known problem when those systems were designed.
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.
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.
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")`
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.
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...
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.
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.
It makes some sense for interoperation when living inside .NET or the JVM, but this was a known problem when those systems were designed.