Kotlin Looks Nice, But…

Published at 18:54 on 17 July 2019

I’m planning on developing an Android app, and to that end I recently downloaded Android Studio. I notice it offers a second option for the programming language of a project, in addition to the expected Java: something called Kotlin.

That prompted me to take a closer look at this language. I’ve worked about halfway through the Kotlin Koans tutorial for the language, and I must say that so far I am quite impressed.

The world needs a more modern alternative to Java. Once I was hoping that C# could serve in this regard, but alas:

  • It falls victim to bigotry (anything that got its start at Microsoft is going to be sneered at in the open source/Unix/Linux world, no matter its merits, no matter that there’s an excellent open-source implementation of it).
  • It runs in its own environment, not the JVM, meaning that switching from Java to C# implies burning bridges. You can’t easily cut over by developing new modules in C# that interoperate with legacy Java ones.

I looked at Scala, which seemed to offer real promise. Then I experimented with it and ran into Scala’s complexity. I was eternally doing battle with the type system, which seemed to frustrate my every attempt to use the language’s powerful features in clever ways.

When I looked at other people’s Scala code for ideas, I was often perplexed, because it was shot through with special features I had not learned yet. Beyond a certain point, it becomes impossible to remember a language’s core feature set. When that happens, readability of code will suffer, because developers will tend to drift apart from each other, each opting to use their own personal idiosyncratic subset of the language’s features.

There is a real cost to programming language complexity, and it is clear to me that Scala is well past the point of diminishing returns when it comes to feature set size.

That brings us back to the subject of this post. Kotlin really seems to be “Scala done right,” addressing the worst of Java’s deficiencies without falling victim to excessive complexity.

Android was Kotlin’s foot in the door, because many Android devices run truly ancient versions of the JVM, versions so old that many of the newer features in Java (without which the language becomes truly dated and obsolete) are absent. The Kotlin compiler can target those old JVM byte codes, allowing one to use modern features even on legacy platforms.

So I’m going to give Kotlin a whirl on my Android app. I will let you know what my impressions of the language are after I’ve had some practice actually coding something meaningful in it.

The pity is that once one does things other than Android software development in Kotlin, the rough edges in its ecosystem quickly become all too apparent. Just out of curiosity I’ve been playing with the Ktor server-side framework. The documentation ranges from flat-out obsolete (and thus incorrect) to simply nonexistent. The result is that even simple things take hours of tedious experimentation to determine how to do.

I’m hoping that Android development goes better, but unless those rough edges get smoothed out, and soon, Kotlin may well end up being stereotyped as an Android-only thing.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.