Kotlin in Action: Beyond avoiding Null Pointer Exceptions?

[Sean Corfield]

I've worked with a number of JVM languages in production (Java, Groovy, Scala, and for the last seven years Clojure) but I haven't tried Kotlin yet.

Nearly all of the talk I've seen about Kotlin focuses on how it helps you avoid the dreaded NPE by introducing the idea of nullable and non-nullable versions of types and requiring explicit handling of null when "converting" between the two.

Aside from that feature, could the authors provide a short "elevator pitch" of why I should consider Kotlin, given the languages I already use?

Thank you.

[Giovanni Montano]

Sean Corfield wrote:I've worked with a number of JVM languages in production (Java, Groovy, Scala, and for the last seven years Clojure) but I haven't tried Kotlin yet.

Nearly all of the talk I've seen about Kotlin focuses on how it helps you avoid the dreaded NPE by introducing the idea of nullable and non-nullable versions of types and requiring explicit handling of null when "converting" between the two.

Aside from that feature, could the authors provide a short "elevator pitch" of why I should consider Kotlin, given the languages I already use?

Thank you.

Kotlin is an extreme rich language. Allow you to use Java as you always you do, plus is much less verbose than Java. And is much more readable.
The feature you mention is just the tip of the iceberg. Another really publicized function is the fact you can use data classes. Googling advantages Kotlin you are going to find dozens of advantages.
But what is really important to know is that does not come without a learning curve. The most advanced features are quite not immediately intuitive to learn.

If you know Scala and Java, Kotlin will be really easy for you. There is a growing community that is even implementing Kotlin on back end with Java Spring, and there are all the prerequisites that is going to grow.
All the people that use Kotlin that I know do not go back to Java, because once you recognize his idiomatic expressions, you will found really not convenient to write in a verbose way back in Java.
Just think over the semi columns for instance as banal example, but if you google the data class I mentioned before you will see that you do not need to write pojos anymore.

Everything become much easier, for instance you declare the constructor on the same line you declare a class, you can get rid of the returns using some = sign
Plus you will program in Android quite easy, and you will be able to understand ios as well, because Swift is really similar.

[EDIT: removed portion moved to its own topic at https://coderanch.com/t/685992/Kotlin-Action-Huge-mistake-documentation]

[Dmitry Jemerov]

If you're using Clojure and are happy with it, I'm not sure if Kotlin has enough to entice you. I haven't seriously used Clojure myself, but from what I know about it, I think that Clojure and Kotlin are expressive in very different ways. Kotlin is built as a modern statically-typed programming language, trying to make the type system both more powerful (through the addition of nullability) and less costly (through the support of type inference, smart casts AKA flow typing, concise class declarations, etc). Clojure, on the other hand, is much more dynamic - it supports the minimum amount of static typing support required by the JVM environment, but it prefers to use hash tables instead of explicitly declared types, and it also allows the code itself to be dynamic through the use of macros.

Of course, Kotlin's approach allows for much smoother integration into the Java ecosystem - e.g. I haven't heard of any significant number of people using Clojure to develop Android apps, while for Kotlin the migration from Java in the Android context is very straightforward, and appeals to many developers. But if you're happy with the libraries that exist in the Clojure ecosystem, then again this might not be relevant.

[Sean Corfield]

Much appreciated Dmitry. There have been some efforts to make Clojure for Android viable but application startup time is an issue (using ClojureScript and going the React Native approach seems more suited).

It sounds, from your answer, that Kotlin's two big "selling points" -- compared to the languages I already know -- are the null-aware type system and the suitability for Android development.

We have quite a few languages now that are much more concise than Java -- it's a good time to be on the JVM!