6 ms·

I don't see a huge difference between Scala's Options and Kotlin's null safety. In Scala, you can still do this: val x: Option[Int] = null

• lmm 10y ago
  In theory you can. But you'd know to immediately fail that line in code review (or better still, enforce it at build time via wartremover). Whereas in Kotlin someMethod(null) might be perfectly legitimate or might not, but you can't tell without knowing the details of someMethod (whether it's a Java method or not).
  • afastow 10y ago
    Maybe I'm missing something but how is that different from Scala or Java? That will fail at compile time in Kotlin if the method is written in Kotlin and has a non-nullable parameter. Even if it's Java I think it will fail at compile time if the Java parameter is annotated with @NotNull. If it is a Java method and not annotated with @NotNull then of course it will be allowed at compile time because how could it possibly not be allowed? What are you saying is preferable in that case?
    • lmm 10y ago
      The trouble is in idiomatic Kotlin you have lines like that, because when you want to represent absence you use nullable parameters. So you can't assume a line like that is wrong. But you can't assume it's correct just because it compiled either, because as you say it might be an unannotated Java method. In idiomatic Scala you would never have a line like that (because you represent absence with optionals rather than null). So you can insta-fail any line like that in code review (or give very careful review in the rare case that it's calling a Java method that accepts a nullable parameter, but good modern Java libraries are moving away from those, so that case should go away).
      • hota_mazi 10y ago
        The main difference is that Kotlin can do both: nullable types or `Option` (and you'd never use `Option` unless you are dealing with it coming from Java, obviously). Scala can only do `Option` since it doesn't have built in support for nullable types. I fail to see how your point shows any superiority from Scala here, it's the other way around. At the end of the day, both languages have nullability support but since it's optional in Scala (because library based), Kotlin's approach is superior in that it requires developers to deal with nullability, while Scala developers can ignore it any time they want.
        • lmm 10y ago
          Nullable types are worse than Option in every way that matters (yes they save a few bytes of memory occasionally, but who the hell cares, if you care about shaving 8 bytes off an object you won't be using the JVM in the first place. It's certainly not worth the cost of working with a weird, second-class type that you can't abstract over like other types). Why do you want an extra way of representing the same thing with more special cases? > Kotlin's approach is superior in that it requires developers to deal with nullability But it doesn't force them to deal with nullability when interacting with Java which is the only case where it matters. Scala calling Scala: you never use null, you never hit a problem with null. Scala calling Java: you have to manually check return values for older libraries but at least passing in null can't happen. Kotlin calling Kotlin: you use null a lot, you never hit a problem with null. Kotlin calling Java: you have to manually check return values for older libraries and won't notice where you're passing in null because that's a normal, safe thing to do when calling Kotlin.
          • hota_mazi 10y ago
            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.
• esarbe 10y ago
  Why on earth would you ever want to do this? This is not how you use an Option.
  • Nycto 10y ago
    That's not the point. The point is that any safety you think you have by using an Option is a little bit hand-wavy. That's not _bad_, but the argument being made by the OP was that nullability in Kotlin was unsafe and inconsistent.
    • esarbe 10y ago
      My argument is that while you use null assignment and nullability in Kotlin, in Scala you don't work with nulls.
      • Nycto 10y ago
        If your entire code base is in Kotlin, then nullability works exactly like Options. The difference is sugar. And the Kotlin compiler can handle null checks as well as the Scala compiler handles Options. The problems arise when you interop with Java. At that point, shit can be null and you just don't know. My point is that it's the same problem in Scala as it is in Kotlin: Java interop adds a measure of unpredictability that needs to be handled at the touch points.
        • esarbe 10y ago
          I agree on all these points.