# Reasons to try Kotlin

For the sake of not having anything more substantial to post for time being - a few reasons you should try Kotlin if you haven’t done so yet, in my personal opinion.

## 1. Less class ceremony

I’d hazard a guess almost any Java developer will have had to deal with devising getters, setters, fields, equals() etc for a class, and know what a menial job it is. Kotlin makes short work of it, with data classes that do all that, all by itself. And should you need to do some custom logic (e.g. getters/setters not backed directly by a field), it won’t stand in your way - in fact, making it easier with explicit language support.

Sure, it is not difficult to write such code - but wouldn’t you rather spend your time on more useful things than writing mandatory ceremony that repeats almost verbatim, class after class?

## 2. Explicit nulls

If anyone claims they have never been tripped by null pointers, I’d question their truthfulness. Arguably one of the original inventors of null pointers, Tony Hoare have said they are a “billion-dollar mistake”, no doubt due to the massive amount of effort needed to diagnose and mend mistakes related to null references.

I should note that I’m not saying that null pointers are inherently bad. They are in fact quite useful - a natural construct for indicating something is missing or doesn’t exist.

The problem lies in the fact that, Java for example, doesn’t support limiting the scope of null pointers at language level - in other words, anywhere a reference can appear, a NULL pointer might appear instead. You either have to check for them explicitly (ceremonial code!), or trust you got it right (until you don’t).

Kotlin nips this problem by making NULLs explicit - you have to indicate that whatever you are returning may return a null pointer, and handle it accordingly. Might seem like a small thing, but it does add to the ergonomics of programming - language doesn’t create extra work for you, but instead helps you do whatever you want to do.

## 3. Convenient string interpolation

1
val example = "Hey \${reader.name}, just look how convenient this is. Can Java do this?"


Enough said. A small thing, but again, ergonomics easily win over Java String.format() calls. As someone who writes code for their day job, even small things matter as they cumulate quite a bit over time.

## 4. Functional programming -friendly design

Kotlin has arguably better support for functional programming than Java. It is a question of opinion how important this is, but for those tending to think in FP terms, it is a huge benefit. From top of my head (non-exhaustively):

• (Higher-order) functions are first class within Kotlin - compare to Java, where you typically have to express such constructs as interfaces and their implementations. In addition, tail recursion is natively supported
• Almost universally available FP methods, e.g. map, sortedBy, associateWith, for writing concise yet powerful data processing code. Java has similar functionality, but it has been added piecemeal over time and just not as convenient to use
• Lazy initialization for variables is easy - var s: String by lazy { ... }. Makes for more concise code as initialization is called only where required

## 5. Strong Java interop

Kotlin has, by design, very strong Java interop capabilities, and is easy to integrate with existing Java code. It is a JVM language after all. If one is not ready to go all-in, why not try a smaller subset first - say, a small library? Of course, there are subtle gotchas related to the way Kotlin architecture differs from regular Java (e.g. static methods vs Kotlin companion objects) - but all of that is thoroughly documented.