Nerd For Tech
Published in

Nerd For Tech

Why Kotlin is a good option for a Java team

Kotlin is not some dangerous mushroom that looks beautiful but you should not eat. Photo made by my wife

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.

Some context

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.

Developer experience

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.

Testing niceties

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 =, deliveryAddress = someAddress). All the remaining Order properties will be filled based on default values.

Null safety

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.

Summing up

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.




NFT is an Educational Media House. Our mission is to bring the invaluable knowledge and experiences of experts from all over the world to the novice. To know more about us, visit

Recommended from Medium

Create a Choropleth Map in Python

Save Money & Offer a Better Experience — It Can Be Done

What Can Be Done About Null? — Cantina

Tutorial Fuzzy Logic Mamdani for Arduino

Tutorial Fuzzy Logic Mamdani for Arduino

How to Be a Successful Software Developer

The best irrigation programmer

Learning dotNet Core — CI/CD

Learning C++: Pointers Part 1

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ürgo Ringo

Ürgo Ringo

Have been creating software for 20 years. Last 7 years worked as IC and team lead at (Transfer)Wise. Currently working as VP of engineering at CleanKitchen.

More from Medium

Why Every Java Programmer should switch to Kotlin

Imitating Kotlin With Java Optional

Taking advantage of Junit 5 extensions

Oh no, another Java Exceptions Blog post