Kotlin in Production: Should you stay or should you go?

In the Android world Kotlin seems to be everywhere. It’s hard to go to a conference or read a blog about Android without Kotlin being mentioned. I remember that at last year’s Droidcon Berlin, most people I talked to already started using Kotlin in production (two months later I published my first app update including Kotlin myself). And indeed, Kotlin made a much bigger impact in the Android community than in the Java community. I’m sure even JetBrains were surprised at this. But it makes sense: Since the beginning of Android, we developers have been stuck with a dated version of a dated language, while other platforms and languages evolved. Kotlin made us competitive again.

The stop sign

But sometimes the enthusiasm of the developers is curbed by the stakeholders. Despite all the great advantages of Kotlin for your code base and velocity, chances are, that you will get a NO for the use of Kotlin. Some of their arguments can easily get dismissed, others have some truth.

Let us look at some:

Everyone in the team needs to learn a new language

An obviously pertinent argument. But the good news: the learning curve of Kotlin is really low. The learning curve of RxJava, for example, is much steeper than that of Kotlin.In the beginning you will write Java style with Kotlin keywords, which works just fine and if in doubt, there is the copy and paste conversion directly build into the IDE.But of course you need to find a way to onboard everyone. And this means time, and time means money for your stakeholders. A great way to start without any risk are the tests. Tests are a safe environment to try out new tools. Begin by migrating your tests or at least write new tests in Kotlin. Actually, Kotlin brings great features that will improve even your test code. After a while everyone will get an idea of how Kotlin works and then you can take the next step.By the way: your team learning a new language is a good thing.

Hard to find developers with Kotlin experience

Actually, most developers are eager to look into new things, and the ones who don’t are not the ones you should consider hiring. So offering applicants the opportunity to use Kotlin will increase the chances of hiring them.We are seeing this with Swift; it’s already hard to find someone who enjoys working with Objective C, and Swift is only 3 years old. The problem is real.Remember the world we live in: a world where we need recruiters to get the best people out of existing projects. We have more positions to fill than developers that apply. Challenging applicants with a new technology is a good way to find the ones that care, and will drive your product forward.

Kotlin is not backed by Google

This is true, but Android relies on byte code. And the byte code from Kotlin and Java will be in the end the same thing. We are only talking about the language we are writing the code in. Google just dismissed the Jack toolchain and confirmed supporting javac compiler for Java8 support. So a bright future here.The true question you need to ask here is, if JetBrains backs up Kotlin for Android. Happily, they totally are committed. It’s a big success story and lots of effort goes in here. Last time a canary(!) build of Android Studio broke something with Kotlin support the next day the fix in the Kotlin plugin was available.Edit: actually Google is already using Kotlin themselves! Check out the databinding compiler for Android. Thanks Ľuboš Mudrák for pointing that out.

It’s too risky to put Kotlin in a production app.

There is no risk for the runtime of the app as of Kotlin. As already mentioned, the language ends when converting to byte code. Probably every library update you are doing is more risky than adding Kotlin, even more features like Null Safety make your code base even safer.Also Kotlin is not a new language anymore. It has been out there for some time, got stable, just got a first feature release. Companies with very large numbers of users switched partially or fully to Kotlin already. If they did take this “risk”, maybe you could also.

Its just another JVM language

You could have written Android apps on every JVM language before but no one did, why should we now? I remember people tried to write Scala apps on Android but it was painful because you needed to deliver the runtime libraries. Kotlin is designed with Android in mind, the runtime is very small. Most of the libraries you use are much larger. This is what’s different now!

We don’t have time to rewrite our app

You don’t need to! Kotlin and Java work perfectly together. You call Java from Kotlin and vice versa naturally. No interop or similar is needed as with ObjectiveC and Swift for example. So you can decide for every single class you write which language works better for you.

A new language slows us down

Uncle Bob wrote about this a while ago: Every new language threw us back in time as our tool chains needed to be written from scratch. Look at Swift, even nowadays, support is not as good yet as Objective C in XCode has. The great thing with Kotlin is that it’s coming from a tools manufacturer. It’s coming from the guys that brought us IntelliJ, the base for Android Studio. The tools support in IntelliJ is as good as Java. Actually it’s so good that Gradleware started supporting Kotlin for Gradle scripts. The reason was the tooling support! Groovy, the current language, although around for many years, never got such a good support as Kotlin already has now.

Also all your code check tools that work with byte code will work out of the box. What’s left might be static check tools that work on source code directly. This is a small step back but will be solved very soon by the community. In the meantime we have Klint as an alternative to make sure we continue to deliver high quality code.

So why do our stakeholders hesitate?

Mobile became core business for most companies. Whatever area you are in, chances are high that most of your customers will find you through the app. But on your core business you tend to be careful with changes, which is totally valid.

Change, the essence of mobile

But let’s also remember: mobile development is defined by continuous change. Other than the backend development world, things change rapidly all the time.In the few years of Android’s existence we had at least three completely different user interfaces: Pre Holo, Holo and Material Design. We had three different APIs to send push notifications over time: C2DM, GCM and Firebase. Just a few years ago the most propagated app architecture would involve a Content Provider that would hide the HTTP calls from you. Your REST client (probably Apache based) would always write results into a SQLite database. Dependency Injection was an anti-pattern due to performance reasons just a few years ago. There was no ReactiveX and functional programming stayed in backend or probably universities.

If we, mobile developers learned one thing, is that change is constant. Building blocks don’t work, as the moment you write them down they might be outdated. An app that hasn’t been touched in 3 years can be thrown away. This was and is still valid on Android. Try to hire a developer who would like to work on an app that still supports Android 2 and/or uses the ContentProvider pattern mentioned above! Good luck with that.

Don’t get left behind

Kotlin is just another of those changes. Don’t miss the change. Who knows, the Java codebase you are protected right now, might end up as what we all call legacy system.

PS: This discussion went viral, so here some translations:Brazilian PortugueseChineseKoreanThai

Source: https://www.flickr.com/photos/dandydanny/10032614756