Kotlin after two months

I’ve been using Kotlin at work for roughly two months now, doing most of my prototyping in it. I wouldn’t say that I’m fully acclimatized yet; I haven’t yet acquired habits that allow me to fully leverage the language’s capabilities (what is the Kotlin adjective that’s equivalent to Pythonic, anyway? Kotlinesque?). But I’m sufficiently fluent that I can quickly knock out experimental prototypes without having to keep going back to the language reference.

Overall switching to Kotlin has been a positive experience, and I’d recommend that anyone doing Android development switch to it over Java (particularly since you can still take advantage of all the Java libraries thanks to interoperability).

But there are a couple of things about the language that are a little irritating, particularly when I’m coding up prototyping that are exploratory and that I’ll eventually throw away. And the reason is that Kotlin is structured to help developers avoid making errors:

• You need to explicitly declare that a variable can be null, and if it can be null, then anytime you use it you need to verify that it’s not currently null. That approach makes null pointer exceptions much less likely.
• You need to initialize variables when you declare them, so that you don’t accidentally access them before you initialize them.
• You need to explicitly coerce your types; no implicit coercion between integers and floats for you. That can be useful to help make sure you’re assigning the right values to the right variables.

But while those characteristics are useful for writing production code, they can be annoying when writing throwaway prototype code. Yes, my variable pointing to some View in my Android prototype might be null. I know it’s not. I’m willing to risk the null pointer crash in a throwaway prototype. And Views in Android? Not available when you instantiate an Activity or Fragment; you have to wait until Android gets around to actually creating them at some point after instantiating your class. That makes initializing some of your variables problematic. And when experimenting with interactions I’m often switching between pixels (integers) and interaction coordinates (floats). I’d like automatic coercion from integers to floats in exchange for my agreeing that I’ve voided my warranty.

So Kotlin isn’t perfect. But then again, no language is. And like I said, it’s preferable to Java. The first time I could doOnEnd {} to an animator (something I need to do all the time), I was totally sold. So you should definitely consider the switch too. Just remember to explicitly coerce your types.