By Xinye Ji
For those who aren’t in Android development circles, Kotlin has been on the rise since its beta release in 2011. At Google I/O 2017, Kotlin was announced to be officially support and adaptation of the language has soared in the last year. I recently decided pick up the language and hope to implement the upcoming features in our products with Kotlin.
Obviously, switching to a new language always has its hurdles. Syntactically, things always take a while before you get into a groove, but that’s always a part of the expected learning curve.
One of the main benefits of Kotlin over Java is that Kotlin seems to value making code a little more condensed. For developers who aren’t particularly fond of Java’s particularly verbose nature, I think this is a welcome change. There aren’t any massive paradigm shifts, but many smaller changes add up to a more streamlined development experience.
But aside from these mostly aesthetic changes, Kotlin takes many design cues from Joshua Bloch’s Effective Java. For me, this had some mixed results. Some of my lazier programming practices cropped up, resulting in me rethinking and revisiting my thought process when implementing some features in my sandbox app.
Thankfully because Kotlin is developed by the same company that produces Android Studio, a lot of these things are pointed out by the IDE itself. For example, my biggest lazy habit was not considering mutability. In Kotlin, one has to declare their variables as mutable or immutable with var or val respectively. If Android Studio, (or rather Intellij) detects that something you have declared is not changed after you’ve created it, it’ll flag that line and suggest you change the it to immutable. If I had to encapsulate a lot of Kotlin’s language design decisions, I’d say that it almost forces you to make better architectural decisions by employing an opt-out mentality, rather than an opt-in mentality.
Overall, I think this makes the learning curve more difficult, as it can produce unexpected behaviors if you haven’t read all the documentation surrounding certain features in Kotlin. But in the long run, I think this will lead to higher levels of productivity.
On a more personal note, I don’t think I have any particular preference towards Java or Kotlin yet. However, I’ve been working with mostly Java for the past few years, so there are still many things I’m still learning about Kotlin as I play around with it more. So one should consider that my familiarity with both languages are definitely not equal. In general, I’d say that (at the very least) trying Kotlin is a worthwhile endeavor for any native Android developer.