Why I don't want to use Kotlin for Android Development yet

Artem Zinnatullin

Even though Kotlin is better than Java in many points it still has significant (in my opinion) drawbacks.

Please treat it as personal opinion & comment if you have solutions for problems listed below.

1) Slow compilation

Small project (~100 classes in total, mostly in Kotlin) takes ~1 minute to assemble. This is simply unacceptable. https://youtrack.jetbrains.com/issue/KT-6246

2) Performance of Kotlin plugin for IDEA

Syntax analysis and highlighting of Kotlin in IDEA (Android Studio) pretty often freezes development machine during typing, unacceptable.

3) Problems with annotation processing

Sometimes it gives random errors and you have to do clean. Almost every day I see complaints about that on different resources. I'm not alone.

4) Mocking Kotlin classes with Mockito is painful

Almost everything is final in Kotlin by default: classes, methods, etc. And I really like it because it forces immutability -> less bugs. But at the same time, it makes mocking via Mockito (which is kind of gold standard in JVM world) painful and goes contrary with language design.

Yes, PowerMock is possible solution, but it interferes with tools like Robolectric and generally it was always a good rule that you should not mock final classes and final method.

I understand that in Java we have that problem of everything non-final by design, but at the same time I don't want to change code just for testing.

5) No static analyzers for Kotlin yet

Yes, kotlinc adds more safety to the code than javac, but if you want to achieve good performance of the compiler you don't want to turn it into static analyzer.

Static code analysis is good for CI, but probably you don't want to run it every time you click on run button in IDE during local development.

Java has: FindBugs, PMD, Checkstyle, Sonarqube, Error Prone, FB infer.

Kotlin has: kotlinc.

Points above were objective, I hope. Points below are more subjective and personal.

6) `==` does `equals()` instead of reference comparison

If Kotlin is "better" Java or "Java on steroids" then it should be better, but not breaking.

Imagine you're in the process of rewriting Java project to Kotlin, you will have Java and Kotlin code at the same time.

You'll have to read and write same code that works differently from language to language. This is one of the reasons why I don't like Groovy.

7) In bad hands operators overloading may lead to bad results

Statement 1: you will need to deal with old codebase written in Kotlin in future. Statement 2: you can add operators overloading to existing java classes via extension functions.

Now imagine you see something like val person3 = person1 + person2 in already written code you need to deal with.

Every project you'll work on may have its own meaning of operators for same classes 😿

Operators overloading is controversial, these links may help you decide (not all of them end with same conclusion):

@artem_zin