Vinted Engineering

At Google I/O ‘17 the Android team announced first-class support for Kotlin. Since then, the language has received a lot more interest from Android developers.

This is great news for Android developers and the whole Kotlin community! Many developers are trying out Kotlin, reading up on best practices or figuring out how to introduce it in their projects.

While we at Vinted have been using it in production since September 2015!

Like many Android developers, we were longing for Java 8 features like streams or lambdas. Luckily, we have an awesome community and tools such as Retrolambda were available. That was a huge improvement and helped us write more readable and concise code - of course, not one without its problems and limitations.
Broken incremental builds, stack trace lines that point to another dimension and even compilation issues were our day to day issues.

Then we came across Jake Wharton’s post on Kotlin. By the way, at the moment of writing that document had 600 active viewers :)
At first, we were suspicious of it, as we are of all new and shiny things. We started playing with it on our personal projects.
It was love at first sight. At least for me. After a couple of workshops and introductions to Kotlin, the whole team felt pretty much like I did :) We fell in love with all the great features like lambdas, null safety, data classes, extension functions and others. Kotlin Koans helped to get familiar with Kotlin syntax and its main features. Now there are a lot of great articles and talks that showcase best aspects of the language. For example this one, also from Google IO, that introduces the most attractive aspects of Kotlin and will help prepare to pitch Kotlin to your team.

We all agreed that it was good. But was it good enough for production? The whole engineering team was really skeptical. Back then Swift had Apple backing it, Kotlin was completely independent and had no support from Google.
I guess the main thing that won everyone over was that Kotlin is completely interoperable with Java and can be used together with rest of codebase without any overhead.

We started from few extension functions, smaller components and unit tests. After we saw improvement in code quality and development speed we decided to go one step further and start converting our existing code to Kotlin. Thanks to JetBrains, doing that with the Android Studio plugin was a breeze. We agreed that all new features must be written in Kotlin. After some help with automation (big thanks to Andrius Semionovas) we removed Retrolambda and improved build times. We then made some tweaks and even restored incremental builds.
Now over 75% of our codebase is in Kotlin.

As early adopters we had our fair share of problems - random crashes, increased build times, issues with annotation processing. Code autocompletion was extremely slow and we had to rebuild whole project often.
But it was really worth it!
Development speed increased dramatically, NPE related crashes disappeared from our crash monitoring tools, our code is much more readable and understandable.

Here’s what our developers think about it:

It makes me think about null pointers - there is no way to avoid that.
I love functional code!
Much less boilerplate.
Higher order functions - no more random one time interfaces!
Say no to semicolons.

Kotlin came a long way since then. Stable was released with full backward compatibility; the community grew considerably and contributed a lot with many great libraries, tools, books and courses.
We are sure that now, after the Android’s team announcement, Kotlin will soon become the first choice among developers.