An overview of why all parts of Instil’s business has switched to Kotlin over the past three years. By an unrepentant Scala Fanboy.

About us

For those who don’t know us, Instil is a software development company based out of Belfast. Typically our engineers partner with other hardware and software providers to offer specialised development, consultancy and training. Three years ago everything we did on the JVM would have been done through Java, but since then all three strands of the business have converted over to Kotlin. We’ve now rolled out our third major Kotlin project and we are a recognised training provider. This blog post is about how and why we did it.

Our Motivations

Often a services company will switch to the ‘technology du jour’ in an attempt to ride the Gartner Hype Curve to increased profitability. Although we have no objections to this (I like cash as much as the next guy) it wasn’t the motivation for our move to Kotlin. We are primarily a Software development company and so were seeking a means to get quality code out the door faster. It turns out that’s what Kotlin gives us. Having proved the case for Kotlin internally we wanted to utilise our expertise gained on the services side, which is why we wrote our own Kotlin courses and started offering consultancy. To put it simply, we’re investing in Kotlin not because we think its a fad but because we are convinced it’s the future.

Why not Scala?

Its probably fair to say the office is divided on Scala. There are the ones that love it and then the rest that are wrong. It remains my all time favourite language for hacking about in but we could not adopt it as a company because:

  1. Scala on Android involves too much complexity and overhead
  2. There were concerns over build times, tool support and integration with our current set of frameworks

So why Kotlin?

I was going to try for an itemised list but all my ideas returned to one central point. Kotlin offers incremental rather than revolutionary change. On both Android and server side codebases (e.g. Spring Boot) you can maintain your current architecture but decrease the size of the codebase by about a third. Developers love it because they can reduce boilerplate without having to resort to libraries like Lombok, plus they can apply functional techniques without the convolutions of Java 8 streams.

Our move to Kotlin across development teams would best be described as uneventful. Existing Java developers converted to the new language easily and we haven’t had any interoperability or tooling issues to speak of. In fairness most of our projects are 6-9 month self-contained applications, so we haven’t had the complexities one would encounter in incrementally porting a monolith millions of lines long. But we believe that our experience will reflect that of most companies making the change. On the services side we have developed a four day Kotlin language course in conjunction with JetBrains which is selling well, and the language is in demand for talks at user groups and conferences (such as my talks at NIDC and CJUG). We’ve helped several enterprise clients build proof of concept applications with Kotlin and so far all have met with success.

An unexpected benefit to emerge from our training courses is that .NET developers transitioning to the JVM tend to embrace Kotlin with an attitude of profound relief. The standard guidelines for writing Kotlin closely parallel modern best practices in C# so its a painless transition, at least when compared to switching from (for example) LINQ to Java 8 Streams.

Future Directions

As happy as we are with our current setup it never hurts to keep an eye on the future. At the moment we can see that:

  1. Developers are becoming increasingly familiar with Functional Programming and procedural programming is in decline
  2. Frameworks that started in the JEE era are either dying (JSF) or being radically re-engineered from the ground up (Spring)
  3. Architecture is back in fashion as new options emerge daily in both the Cloud and the browser
  4. Disruptive technologies like Web Assembly and GraalVM could radically affect language choices

So going forward Kotlin will have to prove it’s not just the best language for today, but a great choice for tomorrow. But as things stand we’re very happy to ride on the Kotlin bus.

KotlinConf 2018

Instil is a silver sponsor at this year’s KotlinConf in Amsterdam and I will be hosting a one day workshop at the pre-conference event. Find out more KotlinConf