Kotlin

Is Kotlin the next big thing?

Friday, April 6, 2018

Before you start to read... yes it is ! This is not your average blog where you would find the answer at the bottom of the page after you’ve read everything isn’t it ?
But the main question is “Why is Kotlin the next big thing ?”

Wait, what?

Let me start from the beginning of Kotlin. It is a free and open source programming language designed by JetBrains. It’s been in development since 2010 and has been ready for use in production since February 2016. In fact, many highly regarded companies have already incorporated Kotlin into their production applications. JetBrains mentioned that adoption is roughly a 50/50 split between Android and back-end JVM server applications. In fact, adoption rates are so high that it’s predicted to overtake Java for Android development within a year. This will make an impact on the type of skills that will be in demand.

Kotlin compiles to Java bytecode and runs on the JVM so it’s suitable for all environments where Java is used. This includes Android as well as back-end server applications. Kotlin is also interoperable with Java in both directions. This allows companies to leverage their existing investments in Java as well as the large collection of open source Java libraries without needing to re-write anything. Kotlin classes can work alongside Java classes and although not required, Java classes can even be automatically converted to Kotlin which enables a very gentle learning curve. When working inside a Java class, Kotlin classes are exposed in a Java-friendly way and vice versa.

Kotlin can also compile to native (eg. for iPhone), JavaScript or WebAssembly for the front end, and even Gradle build scripts can now be written in Kotlin. The idea of implementing the back-end, front-end, and build script all in one language is very promising. Although Kotlin on the front-end sounds strange at first, the benefits are similar to why companies choose TypeScript but with many more guarantees.

 

Sounds cool, but how does it work?

Now lose all the theoretical chitchat and look at the technical stuff why I’m saying Kotlin is the next big thing !

  • Intuitive Equals

You can stop calling equals() explicitly, because the == operator now checks for structural equality:

val john1 = Person("John")
val john2 = Person("John")

john1 == john2    // true  (structural equality)
john1 === john2   // false (referential equality)
  • Default Arguments

No need to define several similar methods with varying arguments:

fun build(title: String, width: Int = 800, height: Int = 600) {
    Frame(title, width, height)
}
  • Named Arguments

Combined with default arguments, named arguments eliminates the need for builders:

build("PacMan", 400, 300)                           // equivalent
build(title = "PacMan", width = 400, height = 300)  // equivalent
build(width = 400, height = 300, title = "PacMan")  // equivalent
  • Properties

Custom set & get behavior can be added to public fields, which means we can stop bloating our code with mindless getters & setters.

class Frame {
    var width: Int = 800
    var height: Int = 600

    val pixels: Int
        get() = width * height
}
  • The Data Class

It’s a POJO complete with toString(), equals(), hashCode(), and copy(), and unlike in Java it won’t take up 100 lines of code:

data class Person(val name: String,
                  var email: String,
                  var age: Int)

val john = Person("John", "john@gmail.com", 112)

And maybe the most interesting feature:

  • Null Safety

Java is what we should call an almost statically typed language. In it, a variable of type String is not guaranteed to refer to a String— it might refer to null. Even though we are used to this, it negates the safety of static type checking, and as a result Java developers have to live in constant fear of NPEs.

Kotlin resolves this by distinguishing between non-null types and nullable types. Types are non-null by default, and can be made nullable by adding a ‘?’ like so:

var a: String = "abc"
a = null                // compile error

var b: String? = "xyz"
b = null                // no problem

Kotlin forces you to guard against NPEs whenever you access a nullable type:

val x = b.length        // compile error: b might be null 

And while this might seem cumbersome, it’s really a breeze thanks to a few of its features. We still have smart casts, which casts nullable types to non-null wherever possible:

if (b == null) return
val x = b.length        // no problem

We could also use a safe call ‘?’., which evaluates to null instead of throwing a NPE:

val x = b?.length       // type of x is nullable Int

Safe calls can be chained together to avoid those nested if-not-null checks we sometimes write in other languages, and if we want a default value other than null we can use the elvis operator ‘?:’:

val name = ship?.captain?.name ?: "unknown"

If none of that works for you, and you absolutely need a NPE, you will have to ask for it explicitly:

val x = b?.length ?: throw NullPointerException()  // same as below
val x = b!!.length                                 // same as above

 

Brent Van Hoof

Newsletter

Stay up to date with our newsletter.
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.