I went to a Kotlin meetup yesterday where Oleksii Fedorov of https://iwillteachyoukotlin.com/ was presenting on this the related topic of how to convince your manager to switch to Kotlin. Lots of good discussion there. I’d argue that leading by example is the best way to do this. Do a spike to enable Kotlin in your project and convert a single class or test. This is extremely easy for most projects. This proves: 1) it works 2) it’s easy, as advertised 3) it can be done gradually (kotlin-java interop is seamless) 4) if you do it right, you can demonstrate the advantages by pointing out how much better the Kotlin class is than whatever replaced it. It also cuts short a lot of debate over complexity, feasibility, etc. I’ve heard of people just doing stuff like this under the radar.
First, Kotlin is relatively new but has been out of beta for a few years nevertheless. It has been adopted by Google as the preferred language for Android. So, most new Android projects are done in Kotlin; it’s a first class citizen in Android Studio. It’s not an optional skill to have for Android developers. It’s been one of the fastest growing languages in the JVM world and people are jumping ship from other JVM languages like e.g. Scala.
Kotlin on the backend has always been possible but got a lot more mainstream with the release of Spring 5.x late last year and Spring Boot 2.x beginning of this year. Both include Kotlin specific features such as extension functions, several spring plugins for gradle and maven to make the compiler do the right thing with opening Kotlin classes and adding default constructors that Spring needs. I’ve switched one project completely and am in the process of switching another project. This is by far the easiest transition of one language to another that I’ve experienced. You’re not switching build tools, libraries, dependencies, etc. Everything stays the same (initially) except you are now writing Kotlin instead of Java. Intellij converts your Java code for you and you can get it working with very little effort (it tends to get some stuff wrong). It’s a great way to learn Kotlin too.
There are many advantages to using Kotlin with Spring Boot but my favorite one is being able to use immutable data classes for Entities, DTOs, etc. and the related feature of having very elegant ways of working with properties (e.g. delegated properties, primary constructors with default values for properties, etc.). If you are doing any kind of Spring code that involves model classes, this clears up a lot of very ugly code. Spring and Hibernate were always a bit broken by design because you had to have setters/getters, default constructors, non final classes, etc. for the reflection based magic that Spring and Hibernate use to work.
The same is true in Kotlin except there you can use compiler plugins to open up spring annotated classes. So you can have a nice closed, immutable data class for your entities and your IDE will never know otherwise. But at compile time, it’s opened up so that Spring can work with it. You get safety and full compatibility with Spring. That’s awesome. Most of my model classes become a one liner:
data class Foo(val field: String, val anotherField: String="defaultValue".
Null safety is another good argument. If you operate servers that run JVMs, just look at all the incidents involving NullPointerExceptions and then ask your self if you’d like to live in a world where none of those incidents would have happened. Kotlin is null safe by default; NPEs are not a thing with Kotlin unless you choose to opt out of the null safety by using
!! or by depending on legacy java code that isn’t null safe. That alone is a great argument to make the switch.
In terms of industry adoption, I’d argue that Kotlin is definitely growing very rapidly already and in particular people from languages like Groovy and Scala are jumping ship. To the extent that people in the Scala community are getting worried about this. Kotlin borrows a lot from both languages and you can think of it as a safer Groovy (statically compiled) and a simpler Scala that has most of its popular features and lacks most of the ugly-ness, failed type system experiments and abandon-ware in the standard library, and complexity that the Scala community has been struggling with.
That will cause two things to happen 1) there will be lots more people with Kotlin skills 2) there will be lots of people wanting to get some Kotlin skills. Both are great when you are hiring for a Kotlin project.