Hypersense and Kotlin programming language

Kotlin has been around for quite some time now, having been open sourced in 2012 and it’s 1.0 version released in 2016. Throughout it’s development it’s been hailed as a fresh new programming language, set to evolve into a serious contender for Java. While we’ve been aware of Kotlin here at Hypersense, we’ve only viewed it as a curiosity, taking note of other developer’s experiences with it especially within the Android community. At the time people seemed to pay a hefty early adopter’s price, and despite the overwhelmingly positive reviews, we decided to not disrupt our development pipeline for some convenient syntax sugar.

All of this changed however when Google announced first class support for Kotlin at their 2017 IO conference. This was a clear sign that Kotlin programming had not only matured into a properly usable language but it also gained the favour of the almighty Google. Surely this meant that it’s time to start paying serious attention to this new player.

We decided then to start using Kotlin programming as soon as possible. The period in which we decided to do this however was a very busy one, with back-to-back projects being the norm. Even though we wouldn’t realistically have the time to test out Kotlin in a simulated production environment, the promise of easier to write and more readable code, along with Google’s endorsement prompted us to simply start a new project in this language. We took a leap of faith and started our latest project 100% in Kotlin.

What comes next is an account of our experience developing our first Kotlin App, without much prior experience. As expected there were a few hiccups, but the overall experience is unexpectedly positive. We will go through the most important good things, and move onto the bad, after which we will conclude with what is in store for the future.

The good

The point of this article is not to create a “Top X reasons to move to Kotlin” kind of list, but to share our experience. So here are a few things we found absolutely delightful about this language, in no particular order.

• Kotlin Android Extensions: This framework deals away with the pesky process of acquiring views. Gone are the days of screen-height ButterKnife imports and longer still the days of using findViewById(). Using the Android extensions we can simply start typing the ID of the view and Autocomplete will do the rest. A word of warning though! If an ID can be found in multiple layouts, one must pay attention to what the AutoComplete window imports. Otherwise you may come across null views and not know why.
• Extension functions: These may seem complicated at first. Adding functions to an already existing class may seem like a daunting task, bringing back war flashbacks from extending classes in Java. In Kotlin it’s as easy as pie. One can even put all of the extension functions in a file and forget about them, no static utility classes, no extra hassle. One great example is adding a method to hide a keyboard that uses a selected view as focus.
• Syntax Candy: We don’t even need to go into details here. There are numerous articles around the web regarding all the various utilities and language specific sugar that are built in, such as this excellent reference from dodyg Even if it’s a well known fact, we just had to mention it on our list.
• Pasting from Java: While we read about this feature we didn’t think to use it. We rediscovered it inadvertently, by moving methods from an old project to the new one. While it isn’t bullet proof, it’s great for simple code copying or POJO migrations.
• Autocomplete: It’s smart. When it’s smart. Jokes aside it’s very helpful especially with syntax specific suggestions. This proved invaluable as we didn’t really have the time to study the documentation from cover to cover.

The not so good

At the risk of sounding like a broken record, the overall experience was positive. As such, the following is a list of not necessarily bad things, but caveats that we came across and found troublesome as novice users.

• Learning curve: There’s not much to the learning curve really, but it has to be mentioned. You’re naturally not going to be at full speed when having just picked up Kotlin. Another thing worth mentioning here is that you won’t be 100% aware of all the goodies and candy available in Kotlin, but maybe this belongs in the good category, as discovering new ways to do things easier is a delight.
• RxJava 2 compatibility: This is a very specific issue, we know, but if this helps anyone it was worth mentioning. Kotlin has a bit of a problem with inferring arguments for RxJava operators that use predicates. The withLatestFrom operator, for example, cannot infer the arguments for it’s predicate. All the links leading to and from this page should explain the situation in sufficient detail.
• Autocomplete: But it has been mentioned as a good thing right? Well it’s a double edged sword, both a blessing as a curse, as one comes to rely on it. Too many a time has it happened that we wrongly assumed that something was broken just because autocomplete wouldn’t know what to suggest. This seems to happen especially with methods from java sources.

The road onward

It would be safe to say that at this point we’re fairly comfortable with both Kotlin and satisfied with the decision to move to it. While at first it’s daunting to pick up a new language, and the general impression is that Kotlin is equivalent to Java, the difference is most notable when one comes back to the latter. It’s only when you start writing Java as if you were in Kotlin that you realise that the syntax is much more convenient and easy to write. Kotlin’s convenience and ease of use creeps up on you so naturally and seamlessly that only going back to Java really makes you feel the difference.

It will definitely be interesting to see how Kotlin is going to tie in with Android development in the future. At this point we can safely say that it seems to fit like a glove for the new Architecture Components that have just been released. If the inference problem is fixed and Android Studio support continues to improve Kotlin is sure to replace Java soon enough.

In conclusion, we wholeheartedly recommend that anyone at least try this up and coming language, and there’s no better place to start than their own tutorial. For us at Hypersense Software, the overall Kotlin programming adoption process was as smooth as we could have hoped and one hundred percent worth it. Now if we could only decide upon a file structure for our project… defining functions in random files outside of classes is probably a bit too much freedom.