The case for Kotlin

Ryan Cooke puts the euphoria about Kotlin into perspective in his post by highlighting some of the challenges in using it for production. He makes some good points, to which I would like to add my own.

He mentions that Kotlin has only recently reached the top 50 in the TIOBE index. Actually I think that’s no mean achievement, given that this ranking is calculated from the number of search engine results for queries containing the name of the language. Kotlin simply hasn’t been around long enough to amass that much internet presence. It says little about growth potential, whereas the recent benediction by Google as a first-class Android language bodes well.

I’m not in favour of making ease of use a main selling point. Kotlin has a learning curve and it certainly takes more than a week to become familiar with some of the more advanced features that the languages has to offer.  As for the lack of a venerable body of standard works comparable to Effective Java or Clean Code I couldn’t agree more. To be able to code to a high standard all our favourite static analysis tools will need to do for Kotlin what they have done for Java.

It takes years for a new language to reach a stable 1.0 release from its inception. To build a mature ecosystem takes at least as long. Being a JVM language Kotlin can piggyback on the huge storehouse of third party libraries and server runtimes. Yet books, tutorials en Q&A content on Kotlin don’t write themselves. There’s also the (initial lack of) experienced experts for hire if the free knowledge base won’t do. Mind however that nothing I mentioned so far is a deficiency of the language itself.

What I do find positively damaging are insincere claims to the tune of “I have become ten times more productive since I switched to language X”. Really? Can you produce in a Monday morning what used to take a full 40-hour work week? I thought no serious developer bandied this silver bullet nonsense in a serious context, but I actually heard it at a Scala meetup (about Scala, of course). I forgot the fool’s name. If writing fewer lines of code were all that mattered we’d still be using Perl. Kotlin’s greatest strength is that it’s maximally expressive with fewer bytes of code without sacrificing readability.

You only get a single chance at a first impression. The problem with exaggerated and unmerited praise is that it puts people off, who then may never come back. Kotlin’s ecosystem is still fledgling. We are still early adopters and to pretend it’s already a Java killer would be disingenuous. The best way to persuade the community that Kotlin deserves to be in the TIOBE top 5 – and I believe it does – is not to feed the hype but just build great software with it. It’s more fun to begin with.