[hota_mazi]

> Kotlin's nullable types and Option are exactly the same thing

I don't think that's accurate.

First of all, Scala's Option is a monad, no such thing with Kotlin's nullable type.

And second, Kotlin's nullability is enforced by the compiler so you can't escape it. In Scala, you are welcome to ignore nullable values whenever it pleases you (or when you forget to wrap them in an Option).

They solve a similar problem but with different approaches and different pros and cons.

[lmm]

> First of all, Scala's Option is a monad, no such thing with Kotlin's nullable type.

Is your point that Kotlin's type violates the monad laws? It does, but all that means is that certain constructs behave in really surprising ways and refactors that look obviously safe aren't. I don't see how that could ever be construed as an advantage.

If Kotlin's type conformed to the laws (which would be a great improvement) then it would be a monad even if you ignored that fact. All ignoring it means is that you don't get to take advantage of some common generic functions, but have to write them out separately every time instead.

> And second, Kotlin's nullability is enforced by the compiler so you can't escape it. In Scala, you are welcome to ignore nullable values whenever it pleases you (or when you forget to wrap them in an Option).

In Scala you're forced to check Options (or, better, handle both cases), so it's the same. Yes, if a "bare" null were somehow to get into your program then you would miss it. But where would that null come from? Only from a Java library and that's exactly the same problem in Kotlin. (Theoretically you could also get one coming out of some really bad Scala code, but the library ecosystem knows better than that, and in your own code you either simply don't do that or you use wartremover to enforce that you never do that)

[hota_mazi]

> In Scala you're forced to check Options

But you're never forced to use them. That's the main problem with Scala's approach: it's entirely er... optional.

The Scala compiler will never tell you "You can't write a.foo() because a may be null".

> Only from a Java library and that's exactly the same problem in Kotlin

No, it's not. The Kotlin compiler will not let such values enter Kotlin code until you've told it precisely whether that type is nullable or not.

Scala has no such mechanism so null values can enter Scala code without the compiler having any say over it.

[lmm]

> But you're never forced to use them.

Use wartremover, then you are. Or just never write "null" (or check for it in code review). Yes ideally it just wouldn't be there, but it's really not hard to avoid it.

> The Scala compiler will never tell you "You can't write a.foo() because a may be null".

But you'll never get yourself into a position where a may be null (unless a came from a Java library, but that exact same problem can happen in exactly the same way in Kotlin). If you need to represent absence you'll use Option, and the compiler won't let you write a.foo() if a is an Option.

> No, it's not. The Kotlin compiler will not let such values enter Kotlin code until you've told it precisely whether that type is nullable or not.

No it doesn't. It lets you silently treat a type returned from a Java library as non-nullable.

[hota_mazi]

> Use wartremover, then you are.

Well, yes, that's my point: that the Scala compiler can't do it, so you need an external tool to do it for you.

It's a similar argument to a dynamic language programmer saying their language is statically typed, you just need to use that external tool to type check it.

> But you'll never get yourself into a position where a may be null (unless a came from a Java library, but that exact same problem can happen in exactly the same way in Kotlin)

Again, no it can't.

Types coming from Java are marked as "platform types" by the Kotlin compiler and they are not allowed in the Kotlin code base. You need to convert them to a bona fide Kotlin type first (basically, decide if it's a nullable type or not).

It's the third time I've mentioned this and you keep ignoring it.

In contrast, Scala happily lets Java types enter the Scala object world, along with its null values.

[lmm]

> Well, yes, that's my point: that the Scala compiler can't do it, so you need an external tool to do it for you.

It's a compiler plugin so the compiler can do it, it just needs a little configuration. And in practice you don't need it.

> It's a similar argument to a dynamic language programmer saying their language is statically typed, you just need to use that external tool to type check it.

No it isn't, at all. The reason that doesn't work for dynamic languages is a) they tend to use inherently dynamic constructs that can't be safely typed b) the library ecosystem often isn't typed or is typed inaccurately. Neither of these things happens in Scala.

The ecosystem doesn't use null, no-one uses null in their code, it's a complete and utter non-problem. It's like the "haskell is no safer than anything else because you can still call unsafePerformIO" nonsense.

> Types coming from Java are marked as "platform types" by the Kotlin compiler and they are not allowed in the Kotlin code base. You need to convert them to a bona fide Kotlin type first (basically, decide if it's a nullable type or not).

Yes except they're implicitly convertible to non-nullable. So in practice it's no better than treating them as non-nullable.