[jankotek]

Optional types are clumsy when compared to modern alternatives:

- Optional does not protect from NPE, null is still allowed

- It adds extra layer of complexity

- some libraries use it, some do not. it is not enforced

- extra typing, Java does not even have type inference and `val` declaration

- `if` expression in java does not return a value, no pattern matching... again far more typing

- no support for chained call on several nullable fields

I use Kotlin for couple of years. It has nullability baked into type system and enforced by the compiler. And it works with existing java libraries.

It feels like going back 15 years to Java 1.4, when I use Optional in Java8 or Scala.

[sid-kap]

True. In practice, though, this isn't a problem. Most Scala code I've worked with just pretends `null` doesn't exist, which is a fair assumption if you're interfacing with well-behaved Scala libraries that never return null.

[pkolaczk]

Kotlin can't abstract over optional types. Scala Option is a monad which let's you do plenty of cool and useful stuff that Kotlin can only dream of. Kotlin solution is actually more complex, because it is baked into the language as a special case with special syntax.

[edem]

Scala is still a baroque abomination which excels in nothing and the advantages are shadowed by its warts. Kotlin is just Turbo Java.

[pkolaczk]

Why so angry? I pointed to one obvious limitation of Kotlin null handling compared to Scala and you're attacking the whole language. Scala and Kotlin both have their place and they are not direct competitors at all, because they have different goals and address different groups of programmers, despite Kotlin drawing actually a lot from Scala. It is actually quite funny, when features in Kotlin are presented as making the language more productive, yet the very same features in Scala are presented as an example of "Scala being baroque abomination".

[edem]

What makes you think I'm angry? I thought that scala was an abomination long before Kotlin came to existence. And I usually compare it to clojure which not only tries but succeeds at being a functional language and on the expressivity scale nothing gets near a lisp dialect. Your comment added no value and you obviously despise Kotlin. From what I see in the city I live: 80% of scala projects fail to deliver and never get to production. The older projects which survive suffer from the slow compiler and the binary incompatibility. Not to mention the arbitrary use of all the tacked-on features by scala devs which makes streamlining code style frustrating from both sides.

[pkolaczk]

"What makes you think I'm angry?"

The wording you used and the fact that your post was a completely off-topic opinion, just to attack the language you don't like. We're discussing various null-safety approaches here, not opinions about which language is better. That Kotlin can't treat optional types as any other monad (e.g. Either or Try monads) unlike Haskell, Scala and probably half a dozen other languages is a fact, not opinion. Also baking optional types into the syntax and the type system makes them language more complex and this is also a fact.

> 80% of scala projects fail to deliver [citation needed]

[xg15]

Also, the type seems to be designed oddly inconsistently in java (differences between Optional<Integer> and OptionalInt, obvious applications like tryGet() missed, etc) and I've read somewhere the designers themself discourage it for many use cases. I don't know why this is the case though.

[throwawayish]

We're using Kotlin extensively at work and a very happy with it. Spending a couple weeks on converting most of our codebases to mostly-Kotlin-little-Java has given a nice boost to developer morale from my PoV.

[nilved]

Nothing you just said is true. Optional doesn't add complexity, it makes complexity explicit. The rest is just Java implementing it poorly.

[jankotek]

And because it is implemented poorly, it adds complexity. Even Scala, which had Option from start, has three ways to return value from Map (Option, nullable return value, and throw an exception if not found). Kotlin has only single way.

[premium-concern]

> (Option, nullable return value, and throw an exception if not found)

Which Map are you talking about? I don't see the method that returns nulls for missing values.

> Kotlin has only single way.

... with the nice side-effect of being unable to tell whether the key didn't exist or if it was null. That's the single worst approach one can take.

[jankotek]

Java maps return null, sometimes I have to use those in Scala.

Most Java Collections does not allow null keys and null values.

[premium-concern]

So you blame Scala both for Java's mistakes as well as addressing them, while Kotlin, which doubles down on Java's poor decisions does everything right? This makes literally no sense at all.

Also, only a few of the newer concurrent Java collections disallow nulls. All the classes commonly used allow null, as well as the collection interfaces themself.

Java had the chance to address this with Optional, but they got the implementation of the null handling completely wrong. Now they are stuck with it, which caused an obscene amount of complexity in the new generics spec to work around it.