[hota_mazi]

I don't know why you keep coming back to the Java interop aspect:

- It's trivial to solve and really not a problem in practice. I'm pretty sure that when you think about and write code, it's 99% in Scala and very little about Java. "Oh, this value is coming from Java and therefore can be null, I'll wrap it in an Option. Done".

- Kotlin and Scala are exactly on the same level when it comes to interoperating with Java. And I bet we solve it the same way: catch the nullable values from Java as soon as possible before they enter the Scala/Kotlin world, and now we're safe again.

The more interesting case for me is pure Scala or pure Kotlin. And I very much prefer Kotlin's approach to nullability for all the reasons I've enumerated, but let's not go over this again.

[interestingemu]

Isn't pure Kotlin a much more unlikely scenario than pure Scala? Kotlin devs certainly take pride at every opportunity of how much Kotlin piggybacks on Java, cf. collections.

I think you can't have it both ways, having a worse abstraction for handling errors while claiming that it works better with Java code and then claiming that "pure Kotlin code" is where the more interesting case is.

[hota_mazi]

No, JetBrains is actually working on Kotlin Native [1].

[1] https://kotlinlang.slack.com/messages/kotlin-native/

[interestingemu]

Yes, exactly, which makes the claim even more baffling.

Sure, they can just reimplement all their Java dependencies, but if they have to implement e.g. collections anyway, they could just have designed a better API in the first place, instead of being stuck with Java collections on platforms that don't even run Java.

[lmm]

> - It's trivial to solve and really not a problem in practice. I'm pretty sure that when you think about and write code, it's 99% in Scala and very little about Java. "Oh, this value is coming from Java and therefore can be null, I'll wrap it in an Option. Done".

That works for values coming out of Java but not for values going into Java.