5 ms·

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, obviou

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.
  - lmm 10y ago
    > - 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.
  - interestingemu 10y ago
    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 10y ago
      No, JetBrains is actually working on Kotlin Native [1]. [1] https://kotlinlang.slack.com/messages/kotlin-native/ https://kotlinlang.slack.com/messages/kotlin-native/
      - interestingemu 10y ago
        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.
- nostrademons 10y ago
  I think there's some misunderstanding about what goes on with an Option<T> type in the compiler. In a sane implementation of Option<T>, there's no space premium for using it over T. The compiler compiles Some<T> to a pointer to T, and it compiles None to null. Swift, Rust, and Haskell all do this; I don't know Scala that well, but I'd imagine it would too unless there's some edge case in Scala<->Java interop. Kotlin's nullable types and Option are exactly the same thing, except with some implicit conversions and smart casts available (marked by the IDE). Using Kotlin & Rust syntax, I make the following mental equivalencies: T? <==> Option<T> maybeNull!! <==> maybeNull.unwrap() maybeNull ?: default <==> maybeNull.unwrap_or(default) maybeNull == null <==> maybeNull.isNone() maybeNull != null <==> maybeNull.isSome() maybeNull?.method() <==> maybeNull.map(|v| v.method()) maybeNull?.method() ?: default <==> maybeNull.map_or(|v| v.method(), default) The comparison is even more apparent if you're used to Swift, which has a separate Optional type but the same syntactic sugar as Kotlin for manipulating it. The two ways that Kotlin nullable types differ from Options in other languages is that you have smart casts (if the compiler can prove that the value is never null, you can use it as a normal variable without explicitly unwrapping), and you have automatic coercions from platform types. Also, I almost never use null in idiomatic Kotlin programming.
  - interestingemu 10y ago
    I think this comment shows a very fundamental lack of understanding how different languages handle errors. In Java (and Kotlin) -- ignoring the topic of exceptions as an alternative -- errors like "missing value" are communicated with null. So in Java you first have an error handling problem, you deal with it by returning null ... now you have a null handling problem! Kotlin tries to put some band-aid around nulls by making them more typed than in Java. In Scala, errors are handled with bog-standard library types like Option, Either, Try, Validation, not some special language built-in. These types are not facilities to handle null (shown by the fact that all these types happily accept null as a valid value), they are facilities to handle errors. They handle errors better than Java or Kotlin, because these types allow developers to choose the appropriate type for a specific error case and retain the structure of a computation. To expand on the second point: Nullable types cannot be nested, Scala's types can and regularly are. This allows Scala to compose operations while carrying errors up to the point where they can be handled easily. If you have an operation returning an Option[T], and want to run an option on the value returning an Either[S, T] then simply looking at the resulting value will tell you if things succeeded or where exactly things went wrong. None --> First operation did not result in a value Some(Left(fail)) --> Second operation failed with cause "fail" Some(Right(value)) --> All operations succeeded with result "value" In Java and Kotlin all you would get would be a bare null, with a probability of people giving up on (typed) null completely and just throwing an (unchecked) exception instead. TL;DR: Kotlin tries to put some band-aid around Java's broken approach of handling errors with null, Scala deals with errors correctly in the first place.

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.
- lmm 10y ago
  > - 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.
- interestingemu 10y ago
  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 10y ago
    No, JetBrains is actually working on Kotlin Native [1]. [1] https://kotlinlang.slack.com/messages/kotlin-native/ https://kotlinlang.slack.com/messages/kotlin-native/
    - interestingemu 10y ago
      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.
nostrademons 10y ago
I think there's some misunderstanding about what goes on with an Option<T> type in the compiler. In a sane implementation of Option<T>, there's no space premium for using it over T. The compiler compiles Some<T> to a pointer to T, and it compiles None to null. Swift, Rust, and Haskell all do this; I don't know Scala that well, but I'd imagine it would too unless there's some edge case in Scala<->Java interop. Kotlin's nullable types and Option are exactly the same thing, except with some implicit conversions and smart casts available (marked by the IDE). Using Kotlin & Rust syntax, I make the following mental equivalencies: T? <==> Option<T> maybeNull!! <==> maybeNull.unwrap() maybeNull ?: default <==> maybeNull.unwrap_or(default) maybeNull == null <==> maybeNull.isNone() maybeNull != null <==> maybeNull.isSome() maybeNull?.method() <==> maybeNull.map(|v| v.method()) maybeNull?.method() ?: default <==> maybeNull.map_or(|v| v.method(), default) The comparison is even more apparent if you're used to Swift, which has a separate Optional type but the same syntactic sugar as Kotlin for manipulating it. The two ways that Kotlin nullable types differ from Options in other languages is that you have smart casts (if the compiler can prove that the value is never null, you can use it as a normal variable without explicitly unwrapping), and you have automatic coercions from platform types. Also, I almost never use null in idiomatic Kotlin programming.
- interestingemu 10y ago
  I think this comment shows a very fundamental lack of understanding how different languages handle errors. In Java (and Kotlin) -- ignoring the topic of exceptions as an alternative -- errors like "missing value" are communicated with null. So in Java you first have an error handling problem, you deal with it by returning null ... now you have a null handling problem! Kotlin tries to put some band-aid around nulls by making them more typed than in Java. In Scala, errors are handled with bog-standard library types like Option, Either, Try, Validation, not some special language built-in. These types are not facilities to handle null (shown by the fact that all these types happily accept null as a valid value), they are facilities to handle errors. They handle errors better than Java or Kotlin, because these types allow developers to choose the appropriate type for a specific error case and retain the structure of a computation. To expand on the second point: Nullable types cannot be nested, Scala's types can and regularly are. This allows Scala to compose operations while carrying errors up to the point where they can be handled easily. If you have an operation returning an Option[T], and want to run an option on the value returning an Either[S, T] then simply looking at the resulting value will tell you if things succeeded or where exactly things went wrong. None --> First operation did not result in a value Some(Left(fail)) --> Second operation failed with cause "fail" Some(Right(value)) --> All operations succeeded with result "value" In Java and Kotlin all you would get would be a bare null, with a probability of people giving up on (typed) null completely and just throwing an (unchecked) exception instead. TL;DR: Kotlin tries to put some band-aid around Java's broken approach of handling errors with null, Scala deals with errors correctly in the first place.