3 ms·

I didn't use Kotlin in production, but non-nullable types are a blessing and a curse. Non-nullable types are long-overdue. However, most Java libraries do not h

I didn't use Kotlin in production, but non-nullable types are a blessing and a curse. Non-nullable types are long-overdue. However, most Java libraries do not have non-nullable annotations. So, even if e.g. method arguments should never be null, they are presented as nullable. You can use external annotations[1], but they are a lot of work. Also, you need to ensure that anyone using your code has the same external annotations, and that they are still correct when a library is updated. There is also a tool that can automatically infer the annotations[2], but last time I tried it was definitely not perfect. Of course, it's possible to live with this, but like Scala a lot particularities of the underlying platform leak into the stronger typing and abstractions that these languages provide. [1] http://blog.jetbrains.com/kotlin/using-external-annotations/ http://blog.jetbrains.com/kotlin/using-external-annotations/ [2] http://blog.jetbrains.com/kotlin/2013/03/kannotator-0-1-is-out/ http://blog.jetbrains.com/kotlin/2013/03/kannotator-0-1-is-o...

gavinking 12y ago
Well it all depends how you handle `null` at the boundary between the two languages. In Ceylon, we let you write either: String str = javaObject.javaMethod(); or: String? str = javaObject.javaMethod(); In the first case, we insert a runtime type check that throws an `AssertionError` if `javaMethod()` returns `null`. In the second case we don't. That is to say, the Ceylon compiler recognizes that it's dealing with a Java library where information about null is simply missing from the method signature and adjusts accordingly.
- quarterto 12y ago
  The first case would be a compile time error in Kotlin. How is a runtime AssertionError better than a runtime NullPointerException?
  - newgame 12y ago
    > The first case would be a compile time error in Kotlin FYI, Kotlin will have the same behavior as Ceylon in the future, i.e. it's going to be a runtime error in the first case: http://blog.jetbrains.com/kotlin/2014/10/making-platform-interop-even-smoother/ http://blog.jetbrains.com/kotlin/2014/10/making-platform-int...
  - gavinking 12y ago
    Well it is somewhat better because it occurs immediately when the null value passes from Java code with unsafe null into Ceylon code with safe nulls. Having the compiler produce an actual error in this case seems wrong and excessive, since the compiler does _not_ know better than you whether javaMethod() can return null. It simply doesn't have that information when calling Java code.
mike_hearn 12y ago
The next release of Kotlin has a change to the type system to make this a lot less painful, apparently. I'm waiting for it before proceeding with Kotlin. As to kotlin vs ceylon, no real strong preference either way, they both seem strong. I'm planning on going with Kotlin longer term because I am already an IntelliJ user and because it has a Java-to-Kotlin converter.

gavinking 12y ago

Well it all depends how you handle `null` at the boundary between the two languages. In Ceylon, we let you write either: String str = javaObject.javaMethod(); or: String? str = javaObject.javaMethod(); In the first case, we insert a runtime type check that throws an `AssertionError` if `javaMethod()` returns `null`. In the second case we don't. That is to say, the Ceylon compiler recognizes that it's dealing with a Java library where information about null is simply missing from the method signature and adjusts accordingly.

quarterto 12y ago
The first case would be a compile time error in Kotlin. How is a runtime AssertionError better than a runtime NullPointerException?
- newgame 12y ago
  > The first case would be a compile time error in Kotlin FYI, Kotlin will have the same behavior as Ceylon in the future, i.e. it's going to be a runtime error in the first case: http://blog.jetbrains.com/kotlin/2014/10/making-platform-interop-even-smoother/ http://blog.jetbrains.com/kotlin/2014/10/making-platform-int...
- gavinking 12y ago
  Well it is somewhat better because it occurs immediately when the null value passes from Java code with unsafe null into Ceylon code with safe nulls. Having the compiler produce an actual error in this case seems wrong and excessive, since the compiler does _not_ know better than you whether javaMethod() can return null. It simply doesn't have that information when calling Java code.

mike_hearn 12y ago

The next release of Kotlin has a change to the type system to make this a lot less painful, apparently. I'm waiting for it before proceeding with Kotlin. As to kotlin vs ceylon, no real strong preference either way, they both seem strong. I'm planning on going with Kotlin longer term because I am already an IntelliJ user and because it has a Java-to-Kotlin converter.