This is a reply to my own post: Why I don't want to use Kotlin for Android Development yet.

Funny thing is that few days after writing that ^ post I was sitting near to @intelliyole from Kotlin team and talking about the language and few weeks later I started working on a production app fully written in Kotlin. Lol, life is strange right? (0 sources written in Java, a little bit of Groovy in tests).

// Please, please treat it as personal opinion.

So, Kotlin is now v1.0.2 .

1) Slow compilation

Almost great now.

clean assembleDebug (with multidex) for our app takes ~1 minute now in average on mbp 15.

I would say that it's now faster than for the app of the same size written in Java with Retrolambda.

2) Performance of Kotlin plugin for IDEA

~Okay.

Well, It's better than it was, but if you delete some code from the middle of the line -> syntax parsing may really slow down or freeze the IDE for a couple of seconds.

3) Problems with annotation processing

Not okay.

It works, but you can be sure in it only if it's clean build. Otherwise, it won't regenerate code and you will probably have crash/misbehavior at runtime.

4) Mocking Kotlin classes with Mockito is painful

Okay.

Yes, we do have a lot of interfaces because of that, but we found a way to structure code in that way that it's easy to navigate/edit/create. Very similar to the solution described here.

But be careful with verifying calls of extension functions, just think before doing it.

5) No static analyzers for Kotlin yet

Not okay.

Will be so great if Kotlin team will extract Kotlin code analysis from IntelliJ and make a Gradle plugin out of it.

Android Lint rules will be rewritten to support both Java and Kotlin soon.

But for sure, compiler is much smarter than Java's. But but but Rust's compiler smarter than Kotlin's and you don't feel that safety after compilation.

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

Okay.

So, my complaint was that in project where you mix Java and Kotlin code == will/may confuse you during code reviews/etc.

But when project is fully written in Kotlin, == feels good and yes, I was wrong about it ¯_(ツ)_/¯.

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

Okay.

If your team is Okay -> then this won't be an issue, especially because you have to import the operator implementation so it does not implicitly come to your code.

We mostly use += for rx.CompositeSubscription . So instead of

subscriptions.add(Observable .fromCallable { doSomething() } … .subscribe { … } )

We write

subscriptions += Observable .fromCallable { doSomething() } … .subscribe { … }

I found only one weird usage of operator overloading in the project, so it totally depends on the team as ^ title says, I was worrying about it too much.

*') Bonus item: finally you can see it in the debugger!

Previously debugger didn't display any local variables and it especially in most of the cases. Since v1.0.2 it works fine now.

Conclusion

Kotlin as main language for Android project feels good now.

Yes, you still fight with language few times a week (mocking, some rarely used syntax, type inference), but it worth it because as a result you get better code.

Happy to change my opinion and admit that I was wrong .