Why Kotlin is a good option for a Java team
Wanted to share my experience using Kotlin as the language for our backend at Clean Kitchen. Based on the last 6 months I’m very happy we made that choice over Java and I recommend any Java team to give it a try.
I have been working with Java for the most part of my career. It’s one thing to look at other languages to expand your general awareness and borrow some ideas into your existing language of choice. However, when it comes to switching the primary programming language for the team/organisation then I’m more conservative and don’t want to make that jump too lightly.
The custom parts of our current backend were originally built by an external agency. They used Kotlin and worked on it for about a year. Then about 6 months ago we set up an in-house engineering team (that’s where I joined as well). Initially our team was 5 engineers.
Due to the changes in our business plan and some technical constraints (related to Shopify that was the basis of our original solution) we decided to build new backend instead of extending the existing one. At that point we had about 1 month of Kotlin experience working on the existing backend code base.
Even though none in our team had worked with Kotlin prior to joining Clean Kitchen we decided to use it for the new backend as well. Our good experience working with Kotlin written by another team gave us additional confidence that we would manage using it from scratch as well.
I’m not a big believer in any language X giving me significantly better development performance because of its features alone. That being said I do believe that choice of technology can have a significant impact on the overall developer experience and happiness. This higher satisfaction can then translate to better performance as well. Assuming of course that the team embraces the new tool.
For Java developers the Kotlin learning curve is quite smooth. IDE support (in IDEA at least) is just awesome. Spring/Spring Boot has official support for Kotlin and we haven’t had even the smallest problems with it.
There are tons of things in Kotlin that make it great to work with. Below are just a few things but this is not meant to be an exhaustive list.
More expressive domain modelling
I’m a big fan of Domain Driven Design. Kotlin has many features that help in building more expressive domain models. It’s not just about saving some typing and not having to use Lombok. Things like sealed classes and value classes enable me to implement models that are closer to the problem domain.
Easier to read interfaces
Another handy tool is extension functions. They allow me to write code like
myDomainEntity.toApi(). Thanks to extension functions I can keep different concerns decoupled while exposing more intuitive interfaces. For example, I can “attach” the
toApi to the domain model entity for convenient usage while defining it in my API layer.
Previously I have used Groovy/Spock for testing Java code. I like Spock and its given/when/then structure. However, writing unit tests in different language is not ideal for driving the production design no matter how similar the languages are.
With Kotlin I can write sentence-like test names like in Groovy without having to duplicate test description in the
DisplayName annotation. Another nice feature is named parameters and default parameter values. These have replaced the need to write any builders for test data. I can just have something like:
anOrder(customerId = someCustomer.id, deliveryAddress = someAddress). All the remaining
Order properties will be filled based on default values.
One thing that people often point out with Kotlin is null safety. While it is indeed pretty cool then for me this is not so a big win. In Java code base you can use some kind of Option type and never assign explicit null value. In my experience this gives pretty similar guarantees to avoiding NPEs without these annoying
if (someValue != null) guard clauses. Of course the difference is that in Kotlin this approach is baked into the language while in Java it must be the team’s conscious design choice.
All these features are of course not mind blowing and some of these things are even being picked up by Java. However, they all contribute in making the overall experience working with the language more pleasant.
Using the tools that are a pleasure to work with and allow one to expand their skills is not a small factor in overall job happiness. Based on this experience I’d say that Kotlin is a low risk choice with clear upside for any Java team open to give it a try.