[ebola1717]

It gives you a type/interface level guarantee.

e.g. you know

    public Optional<File> loadFile(String filename);

can fail to return a file, while

    public Int sum(Int a, Int b);

can't fail to return an Int.

Obviously, because nulls exist in java, this guarantee isn't provable on compilation the way it is in e.g. Scala, but if your entire team writes code this way, at least you can rely on that for internal libraries. Like generics, this is one of those ideas that's ok in java 1.X, but doesn't shine as much until a backwards incompatible java 2.X

[Filligree]

Nullable types provide Optional already. I find the use of a custom wrapper type to be a massive wart, and Optional is a common enough thing that it's worth adding a bit of syntax for it.

Which is why I like Kotlin's approach. Same guarantees, one letter instead of ten. If you're writing Java, though, I can see why Optional has some use.

[eropple]

Nulls exist in Scala. You can return null for an Option[T].

Can't in Kotlin, though.

[kodablah]

When interoperating with other libraries on the JVM you very easily can, which is a very common use case.

[eropple]

You're right. Kotlin provides the null-or-throw operator (!!) to convert a Derp? into a Derp, though.