Kotlin in production, what did we get, and what did we lose?

Since Google made Kotlin a new beloved wife , enough time has passed. And immediately after this announcement, our team started a new project entirely on Kotlin. Let me clarify: not a test or just an internal project, but a new module for a live application with 600+ thousand active users per month. What experience have we learned from this? What did we win and what did we lose?

For a start, I will not repeat the promises of JetBrains at the expense of assembly time, full interaction with Java and performance. It is true that the Kotlin code is almost as fast, and that the overhead does not exceed the size of a typical PNG image from resources. But why do we need Kotlin at all, and what is the difference?

Fan factor

Obviously, Kotlin must first learn. Even though the learning curve does not look like Mount K2, it is not flat either: one colleague noticed that it took him about two times more time to complete tasks on Kotlin, however, no one had ever complained . On the contrary, everyone was just glad to have the opportunity to apply a cool new toy with all its whistles in production. Moreover, in order to attract the best candidates, we did not agree to mention in the course of the interview what we were writing on Kotlin. So the net victory in this category is +100 points to Kotlin.

Speed

Working with a new language is not only the study of its syntax, it is a combination of writing, reading, refactoring, testing, etc. Let us dwell on this in a bit more detail.
')

Writing speed

On average, it took about two weeks to feel more or less comfortable with Kotlin. And it took about two more weeks to start writing on it faster than on Java. It was easier for those who had experience of Scala and Groovy, as the authors of Kotlin were inspired in many respects by them. Support from the IDE is still not perfect: a lot of convenient and familiar Java refactorings and auto-substitutions simply do not work now. But even despite this problem, in the end, we are still a bit of a plus in speed. Kotlin's weak victory in this category, however, we expect more from the final version of Android Studio 3.0 (at the time of this writing, we were still using beta).

Read speed

Although the code on Kotlin turns out to be significantly shorter, it is longer to parse pull requests on the GitHub. Why is that? First, neither Google nor JetBrains prepared a full-fledged style guide, so the team members began to spend more time on discussions on the topic of “beauty”. Even official code samples are not all uniform. Secondly, some new (for Java) constructions can be used to the detriment, while on Java it is not possible to write like that. Total: a small but still a loss in this direction, although, again, we expect improvements in the near future, because we have already agreed on 99% of the controversial cases.

Tools and Libraries

The terrible truth is that Checkstyle and Lint are absolutely useless for Kotlin, and we use them actively, but there are almost no problems with libraries, the same Dagger works fine. And we got Kotlin-X and are going to draw into the Anko project. Here again Kotlin’s loss, and even though Anko with Kotlin-X may sweeten the pill, we don’t particularly expect dramatic improvements in the work of the stackers in the near future.

Testing

And here we suddenly got an advantage. Kotlin does not come with any new tools or libraries for testing, but new language features, especially type inference, extensions, and reified types have significantly reduced the number of boiler plates in test classes. A clear victory here, even though the IDE sometimes tries to run Espresso as if it were pure JVM unit tests and obviously does not cope with the task.

Self development

A new programming language is not only a bunch of new keywords, it is new ways to rewrite old patterns, it is a bit of new paradigms and, sometimes, new ways to think and express thoughts in code. Studying Kotlin, we not only learned how to write in another language, we understood how to make a better part of the code in the old one. And we absolutely definitely pushed ourselves beyond the boundaries of the comfort zone, which, frankly, is also a kind of fan factor, but the fan factor is worth it!

P.S. Initially, the article was written in English for a corporate blog, but I decided that it should also exist in Russian, so the “coincidence” of the authors' names is not accidental.