Migrate to Kotlin or die trying

As you can see from the title, I’m quite much on the bandwagon of Kotlin supporters after this week’s Google I/O. I’ve decided there’s no time to waste and I’d better get to know this Kotlin thingy as swiftly </pun> as possible.

The plan

I really got hyped by the news that Kotlin is now an officially supported Android language as I’m not so into Java really. You see, my first experience with programming was with Python so Java is too cluttered for me even after a year and a half of using it all the time. Over the time I coded quite a lot in Swift as well as Scala and Ocaml so with a bit of knowledge about what Kotlin stands for I was really hyped to try it.

I decided that the best course of action would be to try and add a brand new module to LinuxSession application as I still want to develop it to make it even better for the next year. I got worried about my heavy use of omnipresent libraries in this project as I rely quite a lot on Dagger and Butterknife in it. However, I heard that Kotlin is fully compatible with Java code so I should be able to write just one package using Kotlin and there should be no communication errors. Oh, how wrong I were.

The execution

I downloaded the Android Studio 3.0 Canary 1 which is basically the newest version I could find on the beta channel. I reconfigured the project to get rid of Jack, while preserving Java 1.8 functionalities and talked Gradle into working with Kotlin. I started coding. The tools to convert Java code into Kotlin worked really well for simple cases, however they required some help in certain null-check situations. On top of that, the tools weren’t always able to properly assess fields’ nullability or lack thereof and that needed to be tweaked as well.

The real problems started with Dagger and Butterknife. I literally had to go to google’s second page of results to find the solution to my issue :). Basically there is a compatibility problem between Android’s apt Gradle plugin and Kotlin’s kapt. I had to experiment a bit to make it work and in the end I still managed to break ButterKnife in the process so now it still doesn’t work in certain Java classes. I can assure you though that I will finish up this project using mostly Kotlin from now on.

Unfortunately, lack of time stopped me from doing any more work on LS’s app this week and neither was I able to truly get into all the great innards of Kotlin. Time will come though.

Why bother with Kotlin anyways?

As for now I only had more problems with Kotlin than I would ever have with Java, trying to do the same thing. You may ask yourself then why is it so important to me to make a switch. Well, as I said before, based on my background in programming, I’m really chuffed to bits with some of Kotlin’s features. If you are considering the switch, go forth and read on it but I still will provide you with a short list of my favourite features of this language.

– Null-safety – Kotlin employs the thing that I loved the most in my brief sidetrack into swift development, the nullable values (optionals in Swift). With several shorthands it makes for a really concise and safe way of handling null values.

– Smart casting – another swift-like feature I really loved is the fact that you can check if an object is an instance of a class and if so, execute some operations on it without use of helper variable. It’s done in such an elegant way as well. Go check it out! 🙂

– Functional paradigm – Kotlin is an Object Oriented language but still it allows for a frivolous use of functions as higher-class entities. You can freely pass them as parameters to methods, use lambdas and use a number of shorthands in defining the functions. It reminds me a lot of the way Scala does it. It’s beautiful.

– Extensions – The language got rid of all those pesky utility classes using two easy tricks. You won’t believe the number 2! In all seriousness, I really love when a language allows you to locally extend the functionality of a class without the need of explicitly extending and rewriting it again. You can just add some methods to existing classes (even those in Java)

– data classes – This feature is a murderer of boiler plate code. It turns your 500LOC long POJO model class into concise several lines of code. I’m looking forward to the commits with 20 insertions and thousands of deleted lines :).

Of course this is not the end of all the goodies Kotlin has to offer you but I’m still quite new to it and unfortunately this is all I have time for today. Thank you for Kotlin, Google. Keep up the good work.

Leave a comment

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