Using Kotlin in Production: Wins, Losses, and Lessons Learned

  • Date Published
  • Categories Blog
  • Reading Time 4-Minute Read

It’s been awhile since Google announced Kotlin as a first-class citizen in the Android world. Immediately after that announcement, my team began a new project completely based on Kotlin.

It’s been awhile since Google announced Kotlin as a first-class citizen in the Android world. Immediately after that announcement, my team began a new project completely based on Kotlin. To be clear: this wasn’t a pet or internal project, a demo, or a test; it was a new module for an existing live application with 600k+ monthly users. So what did we learn from our experience? Which advantages did we lose, and which did we gain?

First of all, I’m not interested in repeating JetBrains’ promises about build time, Java interoperability, and performance. It’s true that Kotlin is almost as fast as existing Java code. In addition, it adds almost no overhead to the build time, and it loads our application package file as if it were just a typical PNG image. But what is it that really makes the difference and sets Kotlin apart?

Fun Factor

Obviously, Kotlin has a learning curve. Even though that learning curve doesn’t look like Mt. Everest, it’s not flat; one of my teammates even remarked that it takes approximately twice as much time to get a task done in Kotlin. Nevertheless, nobody ever complained. Mostly, people were excited by the opportunity to touch a brand new toy – complete with all its whistles and bells – in production. In an effort to be yet more attractive to top-quality developer candidates during interviews, we even found ourselves mentioning the fact that we were using Kotlin. So all in all, Kotlin is a clear win on the fun factor: +100 points.

Work Performance

Working with Kotlin is not just about learning the syntax of a new language. It’s the sum total of writing, reading, refactoring, testing, and many other functions. Let’s look at these tasks in more detail.


On average, it took about two weeks to start feeling comfortable with Kotlin, and two more weeks to gain an actual writing advantage. Having Scala or Groovy knowledge helps a great deal, however, because Kotlin was inspired by Scala and Groovy to a good degree. IDE support is still not perfect; many handy auto-completions and refactorings simply do not work at the moment. While that wastes part of the advantage, the overall feeling is still positive. So on the writing front, we only have a meager win. But it’s going to be a bigger win soon, since Android Studio 3.0 was not even released at the time. (Our team uses the beta version.)


Even though the code is much shorter, it takes more time to review the pull request on GitHub with Kotlin. Why is that? First of all, neither the Google team nor the Kotlin team ever provided a proper style guide, so people tend to invent their own and spend time on discussions. Even the official Kotlin code samples are not completely consistent at this time. In addition, some fancy concise Kotlin constructions can be used badly (while Java simply doesn’t allow that). In other words, we’ve got a small loss here on the reading front. But we do expect things to get better over time, since our team already got agreement on 99% of typical cases.

Tools and Libraries

It’s true that Checkstyle and lint simply don’t work with Kotlin yet. But Dagger does. And we’ve also got Kotlin extensions (Kotlin-X), and we’ll embrace Anko as well. So again, we’ve got a small loss here. But Anko and Kotlin-X make this loss relatively subtle. However, we don’t expect to have a decent style checker anytime soon.


Here’s where we got a surprising advantage. There are no new tools or libraries for testing in Kotlin itself, but new features (especially type inference, extensions, and reified type parameters) reduced the amount of boilerplate significantly. This is a clear win, despite the fact that IDE sometimes tries to launch Espresso tests as pure Java unit tests and fails.

Self-Development for the Win

A new programming language is not just a bunch of unknown words. It’s a new way to perform well-known routines, a new set of paradigms, and – sometimes – a new way of thinking and expressing. By learning Kotlin, we also learned how we could construct our Java code in a better way. And we ultimately pushed ourselves out of our comfort zones, which is, to be honest, one more fun factor worth considering.SIT AGENCY PROFILE