Kotlin: A good idea

Since Google’s Android team announced at the Google I/O keynote 2017 its “first-class support for Kotlin,” or, even a little before that for the bravest developers, adopting Kotlin for Android development has been (and still is) a good idea.

Today, I’m not going to focus on the technical benefits of Kotlin. I won’t dwell on the features that make this language the best choice for starting a brand new Android project, and a great one for refactoring or including new features to existing projects, such as being 100% interoperable with Java code (yes, for once, this will be a Plug-and-Play that will actually work). I’ll just briefly mention its flexibility in terms of allowing type inference. And I’ll also avoid going into detail about its expressiveness and let’s-cut-the-boilerplate philosophy, with the great example of the data classes: no getters or setters required, native support for copy(), hashCode() and equals()… or the null-safety the language itself has by default.

That’s not why we’re here today.

Neither am I here to talk about the small, little, tiny, irrelevant, trivial fact that this language is not exclusive for Android development. Or that isn’t limited to run on a JVM, as it can be transpiled into Javascript, used in multiplatform mobile applications or even compiled to run natively on desktop platforms like Windows, macOS, and Linux.

No, I don’t want to insist on any of that. It’s been done. A lot of people have gone to great lengths to prove those ideas, having written posts, articles, tutorials or even books about the subject. I do want to extend my gratitude to Antonio Leiva and Nate Ebel, among others, because their ways of seeing this new language inspired me, first of all, to try it, and then to advocate for the language as much as I can.

Enough with the facts. I want to highlight something way more subjective about Kotlin:

Kotlin is FUN.

Fun, as in having fun developing a new feature, or even refactoring this piece of code that you dreaded to touch for months because somebody else coded it and they’re gone and there was not even a single comment on that block. Ok, maybe that piece is not the best for your first time, but you don’t even need to read a lot about the language to get started. You even have a Java to Kotlin converter in Android Studio! You can use it one file at a time with the Code > Convert Java file to Kotlin file option. Or, if you want to start smaller, you can create a new Kotlin file and paste Java code snippets, which will be automatically converted.

But that’s not fun… per se. The fun part will come in all those situations when you thought “there should be an easier way to do this!” Yes, I’m mostly talking about collections. Removing items while iterating through a list (assuming there’s no iterator here, and remember, Android does not natively support Java 8… not to mention lambdas).

You can also pass functions as parameters, to be applied, for example, to filter items of a collection to transform only those elements you need.

Or with a lot of this static method that you jammed into your “StringUtils” class… now you can use the extension functions to include that little something you always thought the String class failed to include. And you can use it all across your project.

But enough of just me going on about the language, if you want to gain some first-hand experience with Kotlin, without any further commitment, I suggest you visithttps://play.kotlinlang.org/and start playing with it.

In conclusion, Kotlin is not a good choice just because it’s fully supported by Google and because it has JetBrains and a huge community behind it. It’s good because it’s been designed with the best practices in mind. That helps you apply those best practices as well and allows you to have fun coding instead of struggling with programming language limitations.