Note: We have used commission links in this article and marked them with “*”. If an order is placed via these links, t3n.de receives a commission.
Modern features and less code: these are the promises of the still young Kotlin programming language. Developed as an alternative to Java, it is quickly becoming a universal language. Android and web developers should also pay attention.
From Zero to Hero: That was the result of this year’s Stackoverflow developer survey on Kotlin. For the first time the question was asked about the programming language. The result: The language landed in the category of the most popular programming languages, right behind Rust, in second place. More than 100,000 developers were asked explicitly which languages they use regularly and want to continue working with them. Only around half of the Java developers agreed, with Kotlin it was over 75 percent. But where does Kotlin come from so suddenly and why is it so popular?
The Czech software company Jetbrains, best known for the Java development environment Intellij Idea, launched the Kotlin project in 2011. The goal: to develop a better programming language than Java. At that time, the team had various Team projects with a large Java code base and was anything but satisfied with them. But none of the other available languages could meet the company’s requirements either – although these were rather moderate, said Kotlin’s chief language designer, Andrey Breslav, in an interview with the Rebellabs blog in 2013. Essentially, they are concerned with smooth integration into the existing infrastructure, efficient tools and good compiler and runtime performance. In the absence of alternatives, Jetbrains took matters into their own hands and finally released the first stable version of Kotlin in 2016.
The still young programming language, the name of which goes back to an island off Saint Petersburg, where Jetbrains has a branch, provides many modern features. But that doesn’t mean that the language isn’t mature. After all, it took five years to develop before the first stable version found its way to the public.
Anyone who deals with Java and its challenger Kotlin will quickly realize: It makes a big difference whether a language dates from the last century and modern functions were only gradually integrated, or whether the language design was planned with all the features from the beginning that come into play when used in modern projects. Incidentally, this does not only seem to be confirmed at Kotlin, because the first versions of the top programming languages in the Stackoverflow ranking were all published within the last ten years. This applies to Rust and Go, Typescript and Swift. All of them are more popular than the classic programming languages. Python is the only exception with third place.
Java and Kotlin: No either-or
If you have a large Java code base and don’t want to completely rewrite your existing project in one fell swoop, Kotlin offers a charming transition. Because the Jetbrains programming language is compatible with Java. A Java class can be called in the Kotlin code without any problems and vice versa. The source code of Kotlin, like that of Java, is translated into bytecode, which is then read by the Java Virtual Machine (JVM for short).
But if Kotlin has to be translated for the JVM anyway, couldn’t you just write your project directly in Java as before? That is probably not entirely wrong, but Kotlin has some advantages over the veteran Java – and also many other languages. This is not least due to the fact that the language is developed by a company like Jetbrains, which has proven expertise in programming languages with seven IDEs on the market and, thanks to many years of experience with Java projects, knows where the problem is in practice.
Probably the most elementary advantage of Kotlin over Java is the reduction in redundant code. A look at a classic example of project-oriented programming can make this clear: the writing of a specific class for an object. In Java, in addition to the attributes, a large number of setter and getter methods as well as an equal, tostring and hash code method must typically be written. If a class has a few more attributes, a few lines of code come together. When adding additional attributes later, not only must setter and getter methods be added, but the other functions also have to be adapted.
But of course a project has much more than a single class of this type. There the whole thing has to be rewritten in a similar way, or even better: copied together. One of the most widespread programming paradigms is: “Don’t Repeat Yourself.” But how are developers supposed to stick to it when language design fails?
A look at Kotlin shows that there is another way and also reveals one of the language’s most popular features: data classes. There no extra code has to be written for setter and getter methods or for the other functions mentioned above. An excerpt written in Kotlin equivalent to the Java example above only requires a single line of code. This contrast also continues in some other components of the language design. This is how Jetbrains addresses another problem in many languages: null pointer exceptions. Program crashes that occur during runtime because a variable is accessed that points to nothing. They are particularly tricky in seldom used code snippets, as the error tends to only occur after the application has been published. In Kotlin, such errors can simply only occur during runtime if they are explicitly allowed – which good Kotlin code should only rarely do.
Because: Normal variables must not be set to zero in Kotlin by default. If this is sometimes necessary, Kotlin provides the appropriate syntax. A question mark, which is attached to the variable type, allows the zero reference. Now the compiler reports an error when accessing the value of such a variable directly: The variable could point to nothing. Further intelligent syntax then enables access to such a variable without having to use the classic if-not-null query.
What sounds awkward, is in practice a more than useful tool, since less unforeseen things can happen. Programmers have greater control over the program code and what happens to it during runtime.