Comment by microtonal | Hacker News Reader

Comment by microtonal | Hacker News Reader

Parent Full thread

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/ [2] http://blog.jetbrains.com/kotlin/2013/03/kannotator-0-1-is-o...

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.

The first case would be a compile time error in Kotlin. How is a runtime AssertionError better than a runtime NullPointerException?

> 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-int...

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.

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.

Reply on news.ycombinator.com