Pierre-Yves Saumont - The Joy of Kotlin

Pierre-Yves Saumont

Manning

Shelter Island

Although Kotlin appeared in 2011, its one of the newest languages in the Java ecosystem. Since then, a version of Kotlin running on the JavaScript virtual machine as been released, as well as a version compiling to native code. This makes Kotlin a much more universal language than Java, although there are great differences between these versions because the Java version relies upon the Java standard library, which isnt available in the two others. JetBrains, the creator or Kotlin, is working hard to bring each version to an equivalent level, but this will take some time.

The JVM (Java Virtual Machine) version is by far the most used version, and this has seen a great boost when Google decided to adopt Kotlin as an official language for developing Android applications. One of the primary reasons for Googles adoption was that the version of Java available under Android is Java 6, whereas Kotlin offers most of the features of Java 11 and much more. Kotlin was also adopted by Gradle as the official language for writing build scripts to replace Groovy, which allows using the same language for the build and for what is built.

Kotlin is primarily targeted at Java programmers. There might come a time when programmers will learn Kotlin as their primary language. But for now, most programmers will only be transitioning from Java to Kotlin.

Each language has its own way, determined by some fundamental concepts. Java was created with several strong concepts in mind. Its supposed to run everywhere, meaning in any environment for which a JVM is available. The promise was, Write once, run anywhere. Although some may argue otherwise, this promise was fulfilled. Not only can you run Java programs nearly everywhere, but you can also run programs written in other languages and compiled for the JVM. Kotlin is one of those languages.

Another of Javas promises was that no evolution would ever break existing code. Although this hasnt always been true, it has most often been respected. But this might not be a good thing. The main consequence is that many improvements in other languages couldnt be brought into Java because those improvements would have destroyed compatibility. Any program compiled with a previous version of Java must be able to run in the newer versions without being recompiled. Whether this is useful or not is a matter of opinion, but the result is that backward compatibility has constantly played against Javas evolution.

Java was also supposed to make programs safer by using checked exceptions, thus forcing programmers to take these exceptions into consideration. For many programmers, this has proven to be a burden, leading to the practice of constantly wrapping checked exceptions into unchecked ones.

Although Java is an object-oriented language, its supposed to be as fast as most languages for crunching numbers. The language designers decided that besides objects representing numbers and Boolean values, Java would benefit from having corresponding non-object primitives, allowing for much faster computations. The consequence was that you couldnt (and still cant) put primitives into collections such as lists, sets, or maps. And when streams were added, the language designers decided to create specific versions for primitivesbut not all primitives, only those most commonly used. If youre using some of the unsupported primitives, youre out of luck.

The same thing happened with functions. Generic functions were added to Java 8, but they only allowed manipulating objects, not primitives. So specialized functions were designed to handle integers, longs, doubles, and Booleans. (Again, unfortunately, not all primitives. There are no functions for byte, short, and float primitive types.) To make things even worse, additional functions were needed to convert from one primitive type to another or from primitives to objects and back.