My favourite Kotlin features

Last Saturday I sat down with a strong cup of coffee and got stuck into some Kotlin. I thoroughly enjoyed the process and likewise, thoroughly enjoyed the language. Its simplicity, elegance and to-the-pointedness make me envy those lucky devs that use it day-to-day.

Engineers whose job is to create tools for popular programming languages — and the best ones at that — would certainly know a thing or two about each language’s strengths and weaknesses. It was the perfect recipe, and the oven was set at the perfect temperature.

Coincedentally — and to my astonishment — Kotlin is celebrating its 10th anniversary. I still consider it the new kid on the block, even if 142,000 apps are using it with upwards of 380,000,000,000 downloads.

My knowledge of the language is embryonic, to say the least. I’ve roughly spent a total of 7 hours coding in Kotlin, that’s around 3 hours solving Katas on Codewars and around 4 hours creating very simple Android applications — details of which I’ll go into in my next blog. So, I am by no means an expert. Yet, I’ve still managed to compile 5 things that I love about the language.

Clean syntax

The language is clean. And by clean I mean not verbose. As a Java turned C# developer I can acknowledge that sometimes the code I write is verbose. Verbosity however, is sometimes needed for code clarity. Kotlin has managed to reduce verbosity whilst keeping clarity and — somehow — managed to improve code readability (In my opinion). Here’s a few examples of how they’ve achieved it:

Final made simple

In Java to create a final variable — that is, a variable that can only be initialised once — you’d have the following:

final int AGE = 5;

Whereas in Kotlin you have two different keywords to declare variables: val and var.

val age = 5

val being the final equivalent. Much like TypeScript’s const.

Also, you may have noticed that semi-colons are not required. Oh, and there are inferred types, which there are too in Java and C# now, but it’s worth pointing out.

No new keyword

This one caught me off guard. There I was, trying to create my first object in Kotlin:

val person = new Person() // unresolved reference new

The new keyword is so embedded in my hippocampus for object-oriented programming that I thought I’d made some syntactical error, which, of course, I had.

Let’s have some fun

Kotlin is fun, but to define a function all you need is fun.

fun doSomething() {
  // doing something
}

Such a trivial thing, but having a vital keyword only being 3 characters allows you to focus on what’s important.

Not so nullable types

Null references — known as the billion-dollar mistake — have plagued developers for half a century. I can’t imagine a single developer who has not been stung by this hornet. We’ve all attempted to access a member of a null object at some point. NullPointerException or NullReferenceException or Cannot read property of null, I’m sure one of these inflicts PTSD in some of you.

In Kotlin, references are not nullable by default. You have to explicitly make them nullable:

var name: String = "Luke" 
a = null // compilation error

If you want string to be nullable you’d have to use the nullable syntax:

var name: String? = "Luke" 
a = null // all good

So what happens if you want to access a property of name in this scenario? It’d just throw a null reference exception wouldn’t it? Nope:

var name: String? = "Luke";
name = null;
var nameLength = name.length; // Only safe (?.) or non-null asserted (!!.) calls are allowed on a nullable receiver of type String?

Instead, you get a compile-time error explaining what you need to do to access the member, brilliant.

Extension functions

Okay, this one may be a bit of a cop-out as I am predominantly a C# developer and have on numerous occasions, expressed my love for extension methods. Having the ability to write new functions for third-party code whose source is not easily editable is a game-changer.

fun main() {
    var x = 10.4;
    print(x.half());
}

fun Double.half(): Double {
    return this / 2;
}

I also prefer the implementation of extension functions in Kotlin to other languages, there’s less syntactic sugar, which is always a plus from me.

Convert to Kotlin

One of the best parts of Kotlin is its interoperability with Java, making it easy for Java devs to make the transition. JetBrains IDEs allow you to directly convert Java code to Kotlin, by the click of a button, amazing. This is not so much a feature of the language but rather a feature of the tooling.

I don’t believe there’s any tooling to convert Kotlin code to Java, but, why would you? Well, I’m sure somebody, somewhere has this requirement, but for me I’d stick to Kotlin.

Conclusion

Kotlin has met me well. Many decisions have been made with careful consideration from a team of talented individuals oozing knowledge in programming languages.

As mentioned earlier, I’m new to the language, but I like what I’m seeing. And I intend to see more of it.

I’m currently coding an android app to calculate running paces, which will be written about in my next blog if you’re interested.

Thank you for reading this blog, I hope you’ve enjoyed it! Please signup to my newsletter if you did.

Comments

[Timothy Foster]

Kotlin is probably my favorite language I've worked in at length ^^

I really like not needing to specify a class variable three times:

// Java
class Circle {
    private Double radius;
    public Circle(Double radius) {
        this.radius = radius;
    }
}

// Kotlin
class Circle(private val radius: Double)

[Jean-Michel 🕵🏻‍♂️ Fayard]

Actually it's 9 times

// Java
class Circle {
    private Double radius;
    public Circle(Double radius) {
        this.radius = radius;
    }
    Double getRadius() { return radius }
    void setRadius(Double radius) { this.radius = radius }
}

[Luke Garrigan]

Ahh yes, definitely. This is one of those laborious tasks that has been subtly hidden from view with tooling. So used to writing a field and having my IDE generate the constructor for me. That's a good one.