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.