What is Kotlin anyway?
Kotlin is a small island near Saint Petersburg, Russia. As it happens there is a Jetbrains office not that far from it. Jetbrains, being developers of both IntelliJ IDEA and Android Studio, have always been involved in both Java and Android communities. Because of that, in 2011 Jetbrains announced comming improvement upon Java. Creating a brand new language and they would call it Kotlin. As Java takes its name from an island. It is only suitable for Kotlin to also be a namesake of one. That was the beginning of Kotlin.
Dmitry Jemerov, the dev lead of Jetbrains at the time, decided they wanted to create a JVM-based language. Such as Scala and Java, that would have the best of both worlds. Robustness and expressiveness of Scala and fast compile times of Java. Since then, Kotlin drew inspiration from such languages as Java, Scala, Swift and Groovy among others, trying to find balance. They wanted to create a concise, null-safe, fast to code in and comfortable language. Having in mind that “CPU time is cheaper than developers’ time”.
In February 2012 Kotlin was open-sourced. In February 2016 it was officially released with long-term backward compatibility. Finally in May 2017 Google announced Kotlin as the third officially supported language for Android (alongside Java and C++).
The main reason for Kotlin having become so popular in such a short time? The ease of adopting it in existing projects. It is fully interoperable with Java. So you can “translate” your Java code into Kotlin a class at a time and there will be no interoperability problems.
How Kotlin saves you money?
Designer build Kotlin to be really concise, expressive and quick to write. There are many design features that make every developer happy. Using Kotlin in your project gets rid of boilerplate code, reducing the total size of the project. This leads to easier maintenance and cuts the cost of tweaks and fixes. The features inspired by functional paradigm make it so much easier to work with collections of data and asynchronous tasks. Multithreading and concurrency is made much easier with use of Kotlin Coroutines. On top of all that, extension methods provide a trivial way to extend Android SDK functionality without rewriting whole class as is the case with Java. I’ll go over the most liberating features one-by-one to show you that Jetbrains really put its money where its mouth is.
Null-safety
Tony Hoare – the inventor of null reference – calls it his billion-dollar mistake. While they seem unavoidable to all modern Object Oriented languages. Null references are the cause of tons of serious issues with code. The way Kotlin handles nullability (inspired by Swift) is elegant and safe. It almost fully mitigates the risk of the much dreaded Null Pointer Exception. While in Java, every object is inherently nullable, in Kotlin a programmer has a choice. You have to explicitly state whether you want given variable to be nullable or not. If so, you need to say what happens when you try to access its value and it happens to be null.
There is a way to tell the compiler that you are certain that the variable is not null called “scream operator” or !! but it is rarely needed and you are very discouraged to use it as it is the only way to introduce NPEs.
Null Pointer Exceptions are a huge problem in Java. Being really hard to track down and debug properly, especially in more complex scenarios. In Kotlin, with proper usage of null-safety it is really hard to encounter an NPE and even if you do, they are usually straightforward to get rid of.
Functional features
Properly explaining what functional programming means is well out of scope of this article. However it is enough to know that it makes it much easier to dynamically change not only values but also behaviours of certain elements in the program. Java 8 introduced some functional-like features but it did so with two serious issues. For one, they were made really cumbersome to use with the syntax being suboptimal. Additionally, Java 8 is still not 100% officially supported on Android. for a long time it required use of different tools such as Jackchain and Retrolambda. That is why in-built functional features in Kotlin have been really well received.
There are two main ways in which they make it faster, cheaper and more fun to code Android apps. Firstly, working with collections of data doesn’t require you to use the mediocre Stream API from Java 8. Instead you are given a set of consistent, easy to use methods for filtering, mutating, and utilising the collections’ elements in a way that has been considered a standard in other languages for a long time. Moreover, it is really easy to create concise and expressive callbacks and completion handlers for asynchronous actions. Both things make the code much less verbose, more readable, shorter and easier to maintain.
Extension methods
There are certain things that Android SDK wasn’t designed to do but still are really often done by developers. This leads to the rise of Utility-Classes i.e. classes filled with static methods. This is a big breach of object oriented paradigm caused by Java’s inability to add functionality to classes without rewriting them. Kotlin’s extension methods allow you to simply “extend” a class with certain functionality so that instead of
MyImageViewUtilities.changeAnimated(imageView, newImage)
you can use something like:
imageView.changeAnimated(newImage)
resulting in shorter, easier to read code.
Extension methods make it much easier to extend the feature set of pre-existing classes (such as the ones from Android SDK) without the need of rewriting them or spawning tons of Utility classes which break the basic premises of Object Oriented Programming.
Endnotes
There are many other improvements to speed and quality of coding that come from using Kotlin instead of Java but many of them are a bit too advanced for this article. If you are still interested though, I urge you to read up on Kotlin’s coroutines, variance, generics, delegation and Groovy-like DSL.
Kotlin’s interoperability with Java makes it really worth trying in almost all companies. If you have a project with a developer who’s willing to try, allow them to develop one or two modules in Kotlin in an otherwise Java-based project and see how it goes. If you are starting a new short-term project, try to give the devs an option of choosing Kotlin for the job. It will most certainly not cost you any time (even factoring in the time required for them to switch to new language). I would even go as far as saying that if given enough time (maybe one or two projects worth of time) you should notice a better quality code, less bugs, decrease in regressions and faster development. The full compatibility between Java and Kotlin classes make it a no-risk deal.
For added benefit you can follow the development of non-JVM Kotlin Native and Kotlin for Javascript because maybe, in the future, it will become a true multi-platform, beautifully designed language.
