Kotlin in production, what have we got and what have we lost?
- Transfer

For starters, I will not repeat JetBrains' promises about build 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 be learned. Even though the learning curve does not look like Mount K2, it is not flat either: one of the colleagues noticed that it took him about twice as much time to complete tasks on Kotlin, however, no one complained . On the contrary, everyone was just happy about the opportunity to use a new cool toy with all its whistles in production. Moreover, in order to attract the best candidates, we did not agree to mention during the interview that we are writing in Kotlin. So a clear victory in this category +100 points to Kotlin.
Speed
Working with a new language is not only a study of its syntax, it is a combination of writing, reading, refactoring, testing, etc. Let us dwell on this in a little more detail.
Writing speed
On average, it took about two weeks to feel more or less comfortable with Kotlin. And it took about two weeks to start writing on it faster than on Java. Those who had the experience of Scala and Groovy were easier, since the authors of Kotlin were largely inspired by them. Support from the IDE is still not perfect: a lot of convenient and familiar Java refactoring and auto-substitution just do not work now. But even despite this problem, in the end we are still a bit in the plus for 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 writing, we were still using beta).
Read speed
Although the code on Kotlin is significantly shorter, it takes longer to disassemble pull requests on the GitHub. Why is that? Firstly, neither Google nor JetBrains prepared a full-fledged style guide, so team members began to spend more time discussing “beauty”. Even official code examples are not uniform in everything. Secondly, some new constructions (for Java) can be used to the detriment, while in Java they simply cannot write like that. Total: a small but still a loss in this direction, although, again, we expect improvements in the near future, because about 99% of the controversial cases have already come to an agreement.
Tools and Libraries
The terrible truth is that Checkstyle and Lint are still absolutely useless for Kotlin, and we use them actively, but there are almost no problems with libraries, the same Dagger works fine. We also got Kotlin-X and are going to drag Anko into the project. Here again, Kotlin’s loss, and although Anko with Kotlin-X can sweeten the pill, we do not particularly expect dramatic improvements in the work of style checkers in the near future.
Testing
And here we suddenly got an advantage. Kotlin does not come with any new testing tools or libraries, but new language features, especially type inference, extensions, and reified types, significantly reduced the amount of boilerplate 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, could not cope with the task.
Self development
A new programming language is not only a bunch of new keywords, these are new ways to rewrite long-familiar patterns, these are a few 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 better parts of the code in the old one. And we definitely pushed ourselves beyond the boundaries of the comfort zone, which, to be honest, is also a kind of fan factor, but the fan factor is worth it!
P.S. Initially, the article was written in English for the corporate blog, but I decided that it should exist in Russian, so that the “coincidence” of the names of the authors is not accidental.