Why I love Kotlin (on the backend) ❤️

Kotlin is a very nice language to write backend code that is expressive and concise, yet clear and readable. If you are writing backend code, and especially if you’re using Java, I believe you should take a good look at Kotlin.

I recently came across a post called My Thoughts on Kotlin: Perspectives after 4 years by Tyler Russel. It made me happy to see someone else who recognizes that Kotlin is a really nice language for backend development. He also makes an excellent job of describing the pros (and cons) of Kotlin, so I will not repeat that. I will however add some additional thoughts on the subject.

A sweet spot between Java and Scala #

During the last decade, I’ve worked several years with each of Java, Scala, and Kotlin. Ten years ago, Java was still the “verbose and boring enterprise language” you knew you could rely on, but that wasn’t particularly exciting. (Since then, Java has been updating itself with an impressive speed. In many aspects, it has actually caught up with Kotlin.)

If Java was the boring dependable choice, Scala was an exciting academic experiment mixing object-oriented and functional programming that worked better than anyone expected. However, by the time it was beginning to reach critical mass, its creators preferred advancing their research over making it a dependable choice for commercial projects. It also had large and complex set of features. So much that consultancy firm ThoughtWorks, recommended that to successfully use Scala, you need to research the language and have a very strong opinion on which parts are right for you, creating your own definition of “Scala, the good parts”.

Kotlin was introduced in 2011 as a “better Java” and one take on “Scala, the good parts”. In the words of JetBrains (the creator of Kotlin and the IntelliJ IDEA family), we want to become more productive by switching to a more expressive language. It was clearly inspired by Scala, and supported functional programming concepts, but with fewer features.

For me, Kotlin is kind of a sweet spot between Java (before) and Scala. It was much more expressive yet concise than Java, but less crazy and “academic” than Scala. It had almost everything I wanted, and skipped the rest.

An approachable level of functional programming #

Compared to Scala, Kotlin includes far fewer functional programming concepts. But in my book, that is not bad. It contains the most important parts like first-class functions, immutable data structures, recursion, and more. However, it skipped things like higher-kinded types, full pattern matching, and currying. Perhaps most visible, it opted for built-in support for null-safety rather relying heavily on monads. I think that is the right choice for many developers and it solves almost all cases I come across in my work with less boilerplate.

Kotlin also played a large role for me and my colleagues in developing functional foundations, the set of functional programming concepts that I’ve have found helpful in everyday programming.

Easy-to-use null safety #

I find Kotlin’s approach to nullable types and null-safe operators easy to understand and use. It it is also very similar to JavaScript, C#, and Swift, so it is familiar to many developers.

I really don’t miss the sometimes excessive amount of Option and Either monad wrangling I had to do while working in Scala.

And every time I return to write some Java code, I find myself feeling dirty for using nullable types. 😛

Just the right level of verbosity #

Java has always been known for being a verbose language. While I can sympathize with the idea of that the readability of code is important, it just is too much for me. Add to this the “Java bean” convention which advocates for explicit getters and setters for each field, and you’ve got more boilerplate than I care for.

As for Scala, it is pretty good, though parts of its community are a bit too fond of operator overloading and implicit conversions for my taste.

I think Kotlin hits a sweet spot in verbosity. I feel that Kotlin code tends to be clear and concise, without being either verbose or cryptic. Primary constructors, type inference, and data classes work really well to reduce boilerplate in everyday code.

The difference between a Kotlin data class and a typical Java bean-convention class is pretty extreme. What usually took a whole file in Java could be written in one or a few lines of Kotlin while making it easier to read. (With records, Java has reduced the gap by a lot, though they are a little bit more bare-boned than data classes. It will also be interesting to see how widely they are adopted over time.)

Great standard library (especially collections) #

Tyler already described this well, but I just wanted to say it again. The collection-related parts of the standard library are great. They are based on the well-known Java collection framework, but add lots of really useful and expressive functionality. Working with filter, map, groupBy and friends allows me to write expressive-but-not-incomprehensible data conversions. I really miss them when I work in, for example, Java or TypeScript.

What about the future? #

While I have no plans to stop using Kotlin in the foreseeable future, I am a bit worried.

In line with what Tyler points out, I believe JetBrains are both a responsible steward of Kotlin as well as its worst enemy. Partly because they are making it hard to work effectively with Kotlin without IntelliJ in order to protect their revenue. But also because their strong focus on Kotlin Multiplatform leads to, to paraphrase Bilbo, Kotlin feeling sort of stretched, like butter scraped over too much bread. Especially for me who really only cares for Kotlin as a JVM language.

I am a bit worried that the “golden age” of Kotlin may be over. Java is being developed at a furious pace, and is feature-by-feature catching up to Kotlin. While I still think Kotlin’s syntax is far nicer than Java’s, I think Kotlin risks a fate similar to Scala, where it slowly fades away. At least for backend development. At the same time, the Java landscape may become very fragmented from code bases running on anything from Java 8 to whatever the latest version is at that point.

On a positive note, many of the changes in Java are beneficial for Kotlin too. Especially the work in projects Loom (light-weight virtual threads) and Valhalla (introducing high-performing value objects) will be just as valuable for Kotlin as for Java.

In the end, I can really only wait and see. But I hope Kotlin can keep up and stay relevant even in the coming decade. Otherwise I may have to find a new language to love. 💔