For the uninitiated, Kotlin is a relatively new language that is taking the programming community by storm. In the jungle of thousands of programming languages, Kotlin grabbed attention when Google announced it as the officially supported language for Android development at Google I/O in May 2017.

https://www.youtube.com/watch?v=d8ALcQiuPWs

 

What is so special about Kotlin? Should you consider Kotlin for your next project? This article gives a bird eye-view.

Kotlin Takes the Crown as the “Better Java”

Given Java’s popularity and #1 position, the “Better Java” title is not just about beating Java but becoming #1 programming language. Because of this, all application programming languages get compared against Java. While Java kept losing some developers to these languages over the years, it still manages to retain the top spot. In spite of the widely discussed nuances of Java, the programmers –by and large– would not switch to other languages, because there were always some shortcomings of the newer languages as compared to Java. (We covered why Java remains popular in our post The Irresistible Charms of Java).

With Kotlin, the wait for the “better Java” seems to be over. While Kotlin is still far from Java’s #1 position, it has climbed rapidly into the top 50 languages in June 2017. Google Developer Groups are covering Kotlin workshops with great interest and there is a lot of uproar over the net, so for sure it will be spreading rapidly.

Kotlin claims the “Better Java” crown, because:

1. It hits where Java hurts – It does away with senseless getter/setters that are needed in Java. It has a neat way to avoid null pointer exceptions. It uses syntactic sugar and a little bit of functional programming to reduce the number of lines of code and make many programming tasks trivial. Java cannot implement these cool features because it would otherwise break backward compatibility.
2. It provides interoperability with Java – Instead of re-inventing the wheel, Kotlin works perfectly with Java. It can use Java libraries and frameworks, so on day 1 it already has a rich ecosystem.
3. It does not let you sacrifice the robustness – Static typing avoids a certain class of possible errors and hence a must for robust, enterprise-grade systems. However, a lot of Java’s verbosity is attributed to it. Kotlin not only retains static typing in its full fervor, but it does so while being concise, and further contributes to more robustness (in terms of var/val distinction and null pointer treatment).
4. The syntax is clean and readable – It is readable even to those who do not understand the syntax of the language. The designers of Kotlin have deliberately kept away the constructs that could make the code hard to read.
5. It rolls out a red carpet for the Java developers to switch – Kotlin is just a few concepts away for a Java developer. Apart from a short learning curve, there is an automatic Java to Kotlin converter. Finally, the interoperability promise is that you can convert your Java project to Kotlin one-file-at-a-time instead of doing a complete conversion.

One may notice that the dynamic programming languages such as Python and Ruby lose out on the support of static typing. Scala is a close contender with Java interoperability, powerful functional programming support and more abilities than Kotlin. However, it loses out because the learning curve is pretty high and the syntax can become obscure. Here is a good article comparing Kotlin vs Scala. Although coming from Kotlin camp, the arguments are quite well-balanced.

Kotlin Targets More Beyond Being Just a Better Java

As we saw before, Kotlin establishes itself as a good language aimed at robustness with a clean and concise syntax, and woos the largest chunk of developers (read: the Java developers) with its superior features. But the language designers are not satisfied with just a better Java. With the Java use case as a foundation, they are moving to pastures where other languages have established themselves.

A good example is Javascript which has established itself as the de-facto language on the browser platform and on node.js server-side framework. If you need a type-safe version of Javascript, then you need to use Typescript which essentially creates Javascript code. Similarly, Kotlin programs –which are also type-safe as we saw before– will also generate Javascript code. However, between Typescript and Kotlin, Kotlin is a much better language. Also, developers who flock to Kotlin from Java side will anyways find it easier to code in Kotlin than learn the nuances of Typescript (or even Javascript, which is not as straightforward to understand as one would like it to be).

By generalizing the Java and Javascript use cases, one can see how Kotlin is going. On any given platform, Kotlin would just compile into the de-facto standard of the platform. This minimizes any friction because from day 1, Kotlin has all the necessary features that are needed for developing on the platform. They are already working on Kotlin native which can be used on small devices in IoT and they are also looking at going to the iOS platform as well.

This translates into a great advantages for the developers who learn Kotlin. They will be able to practically code to almost any platform as they desire in Kotlin itself.

As a small digression, it is interesting to compare the Kotlin strategy with the strategy that Java had applied and which helped Java spread and become number 1 for so many years. Java also targeted to be on every platform, on every device. Remember their famous slogan “Write Once, Run Anywhere”? One can say the same thing now about where Kotlin is heading. However, there is one significant difference. Java went to every platform with its “Java Virtual Machine (JVM)” technology. The USP was more of the JVM technology than the language features. Today, Kotlin’s strategy is to use the existing technology but with superior language capabilities.

Start a Kotlin Project: “The Python Paradox” Will Work Out for You

Even with all its superiority over Java, it does not happen that all developers migrate to Kotlin overnight. The ecosystem takes some time to catch up, and so the language would take time for it to become mainstream. In terms of technology adoption cycle, we are at a point where the early majority has slowly started coming in. (Google’s push helped here.)

While the masses are still not there, this would be a great time to start a Kotlin project. When Python was at a similar phase of technology adoption, Paul Graham argued that starting a project in Python would attract smart developers, because only those who genuinely love to do coding would have learnt Python then. The same argument goes today for Kotlin. Start your next project in Kotlin and you are sure to get only the good programmers on it.

Also, given how Kotlin is rising, it would be a safe bet to project that there would be a sizable number of Kotlin programmers around us in future, to help maintain and enhance the Kotlin projects.