4 ms·

> If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala? For all

> If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala? For all the features it has that Scala doesn't of course, many of which may not be part of the core language (compile times, tooling, backing, simplicity, compile-time null safety, coroutines, quality native compilation, Android support, etc).

lmm 8y ago
The claims about null-safety are pure FUD; once you get past thinking about the literal string enn-you-ell-ell, Kotlin and Scala are exactly as null-safe as each other in all the ways that matter (e.g. as shown in the article, Java interop in Kotlin has exactly the same null-safety issues as in Scala).
- eropple 8y ago
  Java interop in well-designed Kotlin or Scala is pushed to the edges of the application and fenced off. Kotlin makes null safety a much more practical proposition at that point where Scala doesn't. To be frank, Kotlin's null-handling is one of the bigger reasons I think lesser-skilled developers should use it over Java. And Scala's is good enough, but it's not as good as Kotlin's. Scala has plenty of other beams in its eye to deal with before getting on anybody else, though (this week's shitfire: developers thinking implicits are a good idea, much as it's been for the last five years...).
  - lmm 8y ago
    > Kotlin makes null safety a much more practical proposition at that point where Scala doesn't. Nonsense. Putting Option() around any Java-interop calls is no harder than putting explicit "?" types on their return types.
    - eropple 8y ago
      I think it's rather significantly different. The range of inputs to a function in Scala are Some[T], None, and null, whereas in Kotlin they become T and null. Kotlin also uses annotations that exist in libraries--and it understands a lot of them--to turn T! into T or T? directly when it can, which Scala doesn't. Can you explain how this is so similar to Scala in a way that leaves it up to you to be contemptuous and spit stuff like "nonsense" at people looking to discuss the topic in good faith?
      - lmm 8y ago
        > The range of inputs to a function in Scala are Some[T], None, and null null is not a legitimate value in Scala. There is no reason to ever use it in a legitimate program; in a situation where you would use null in Kotlin, you use None in Scala. The languages are exactly equivalent (except that Kotlin has confusing inconsistent behaviour when you start nesting possibly-absent types, particularly in the presence of generics), people just get confused because they fixate on the literal source string "null" (and Kotlin marketing encourages this confusion). If you really can't stop yourself from typing n-u-l-l for some reason, use wartremover. > Kotlin also uses annotations that exist in libraries--and it understands a lot of them--to turn T! into T or T? directly when it can, which Scala doesn't. Those annotations are often unchecked and therefore unreliable, in the cases where they're even present at all (which are unlikely to be the cases where you need to interop with Java - popular mainstream libraries have them, but those are precisely the libraries for which there tends to be a native Kotlin/Scala replacement available). In any case, the original article is talking about the case where there aren't such annotations. > Can you explain how this is so similar to Scala in a way that leaves it up to you to be contemptuous and spit stuff like "nonsense" at people looking to discuss the topic in good faith? Sorry. I've seen enough bad faith from Kotlin people on this topic (and when talking about Scala generally) that I find myself unable to assume good faith.

lmm 8y ago

The claims about null-safety are pure FUD; once you get past thinking about the literal string enn-you-ell-ell, Kotlin and Scala are exactly as null-safe as each other in all the ways that matter (e.g. as shown in the article, Java interop in Kotlin has exactly the same null-safety issues as in Scala).

eropple 8y ago
Java interop in well-designed Kotlin or Scala is pushed to the edges of the application and fenced off. Kotlin makes null safety a much more practical proposition at that point where Scala doesn't. To be frank, Kotlin's null-handling is one of the bigger reasons I think lesser-skilled developers should use it over Java. And Scala's is good enough, but it's not as good as Kotlin's. Scala has plenty of other beams in its eye to deal with before getting on anybody else, though (this week's shitfire: developers thinking implicits are a good idea, much as it's been for the last five years...).
- lmm 8y ago
  > Kotlin makes null safety a much more practical proposition at that point where Scala doesn't. Nonsense. Putting Option() around any Java-interop calls is no harder than putting explicit "?" types on their return types.
  - eropple 8y ago
    I think it's rather significantly different. The range of inputs to a function in Scala are Some[T], None, and null, whereas in Kotlin they become T and null. Kotlin also uses annotations that exist in libraries--and it understands a lot of them--to turn T! into T or T? directly when it can, which Scala doesn't. Can you explain how this is so similar to Scala in a way that leaves it up to you to be contemptuous and spit stuff like "nonsense" at people looking to discuss the topic in good faith?
    - lmm 8y ago
      > The range of inputs to a function in Scala are Some[T], None, and null null is not a legitimate value in Scala. There is no reason to ever use it in a legitimate program; in a situation where you would use null in Kotlin, you use None in Scala. The languages are exactly equivalent (except that Kotlin has confusing inconsistent behaviour when you start nesting possibly-absent types, particularly in the presence of generics), people just get confused because they fixate on the literal source string "null" (and Kotlin marketing encourages this confusion). If you really can't stop yourself from typing n-u-l-l for some reason, use wartremover. > Kotlin also uses annotations that exist in libraries--and it understands a lot of them--to turn T! into T or T? directly when it can, which Scala doesn't. Those annotations are often unchecked and therefore unreliable, in the cases where they're even present at all (which are unlikely to be the cases where you need to interop with Java - popular mainstream libraries have them, but those are precisely the libraries for which there tends to be a native Kotlin/Scala replacement available). In any case, the original article is talking about the case where there aren't such annotations. > Can you explain how this is so similar to Scala in a way that leaves it up to you to be contemptuous and spit stuff like "nonsense" at people looking to discuss the topic in good faith? Sorry. I've seen enough bad faith from Kotlin people on this topic (and when talking about Scala generally) that I find myself unable to assume good faith.