First Impressions of the Kotlin Programming Language

In the introduction of the previous post I wrote for this series, First Impressions of the Rust Programming Language, I alluded to the presence of arguments that programming language safety should be achieved by moving to languages such as Java which run on a virtual machine. While "safety" may no longer be the first thing that comes to mind in discussion of these languages, especially with the hundreds¹ of vulnerabilities in various implementations of the Java virtual machine, it would be unfair to deny that the principle of running programs in a sandboxed virtual machine is safer than running machine code directly. This post won't be making any claims about safety, though, as I'm more interested in writing about my impressions from a language design perspective. So, how does Java fare in this regard?

My first run-in with Java was when I was 16 and still in high school; I had enrolled in AP computer science, of which the curriculum was and still is taught using Java. I already knew Python and C at that point, but enrolled anyway as I was never given a formal computer science education, and because the idea of university credits was enticing to me. The portion of the class that regarded concepts of computer science – algorithm design and data structures – was a blast, but I quickly became frustrated with the programming assignments because of Java's horribly unwieldy nature. Despite my distaste for the way the course was taught, my grades stood out enough that the teacher approached me about working as a teaching assistant the following year. I took him up on the offer, and suffered. The position involved troubleshooting students' issues during lab periods, and nearly every time I sat down to help a student, the issue was with one of Java's numerous pitfalls rather than a conceptual misunderstanding of computer science. At of the time of writing this, I have just completed my first semester of university, and Java is apparently inescapable; I have been forced to use it once more in my introductory data structures course. It has not grown on me at all in these past three years, and I am not exaggerating when I say that the language has literally given me nightmares.

Refusing to use Java outside of my coursework would seemingly prevent me from programming for any platform which makes use of Java, such as Android, but it turns out that there's an alternative: using a language that compiles down to the same bytecode as Java does. For those not in the know, Java works by compiling source code ahead of time into a Java class file, which is a container format for JVM bytecode. Bytecode is comparable to assembly, but it doesn't run on actual hardware.² Instead, it runs on an abstract machine implemented in software. JVM bytecode as a compiler target is not a new concept; there are plenty of languages targeting the JVM specifically, such as Groovy, Scala, and Clojure (the latter of which I hope to cover in a future post), but Kotlin was the first I heard of.

While targeting Android is what I ended up using Kotlin for, my initial reason for learning it was not nearly as practical. For context, I go between phases of absolutely hating everything related to Java and phases of almost being able to tolerate it, but that tolerance is mostly out of curiosity about the implementation – the most recent case of piqued interest coming about through obtaining the J2ME JAR for Doom RPG and having an inclination to indulge in some retro Java (circa JRE 1.3) reverse engineering. Really, I wanted to learn Kotlin so that I could compare the bytecode generated by the Kotlin compiler to the bytecode generated by past and present Java compilers,³ but I won't be talking about that much in this post.

Throughout this post, I'll be treating Kotlin as a language that only runs on the JVM, but it's worth noting that the compiler has recently gained support for targeting Javascript and LLVM as well, so this perspective doesn't fully represent the language.

As my first foray into writing nontrivial⁴ Kotlin, I decided to write a version of Minesweeper, my favorite logic puzzle. The code is available on sr.ht. Implementing Minesweeper might be a bit redundant as F-Droid already has a GPLv3'd implementation of Minesweeper in its repositories, but that one's implemented in C++, QML, and Javascript.

For the purposes of illustration, here's a simplified implementation of the Minesweeper logic sans Android API:

data class Tile(val adjacentMines: Int = 0, val mine: Boolean = false, val masked: Boolean = true)

/**
 * The Minesweeper "grid", containing instances of [Tile].
 */
class Grid(val width: Int, val height: Int, val tiles: Array<Tile>) {
    constructor(width: Int = 8, height: Int = 8, mines: Int = 10)
    : this(width, height, Array<Tile>(width * height) { Tile() }) {
        for (i in 0 until mines) {
            val x = (0 until width).random()
            val y = (0 until height).random()
            placeMine(x, y)
        }
    }

    private fun index(x: Int, y: Int) = y * width + x
    private fun valid(x: Int, y: Int) = y in 0 until height && x in 0 until width
    private fun place(x: Int, y: Int, tile: Tile) {
        tiles[index(x, y)] = tile
    }

    /**
     * Returns the tile at the given coordinates.
     *
     * @throws IllegalArgumentException if the X coordinate is outside
     * the range of [0, width), or if the Y coordinate is outside the
     *  range of [0, height).
     */
    operator fun get(x: Int, y: Int) = if (valid(x, y)) {
        tiles[index(x, y)]
    } else {
        throw IllegalArgumentException("Invalid coordinates (${x}, ${y})")
    }

    /**
     * Places a mine at the given coordinates.
     *
     * @throws IllegalArgumentException if the X coordinate is outside
     * the range of [0, width), or if the Y coordinate is outside the
     *  range of [0, height).
     */
    fun placeMine(x: Int, y: Int) {
        if (!valid(x, y)) {
            throw IllegalArgumentException("Invalid coordinates (${x}, ${y})")
        }

        if (this[x, y].mine) {
            return;
        }

        place(x, y, Tile(mine = true))

        val xMin = (x - 1).coerceAtLeast(0)
        val xMax = (x + 1).coerceAtMost(width - 1)
        val yMin = (y - 1).coerceAtLeast(0)
        val yMax = (y + 1).coerceAtMost(height - 1)

        for (y in yMin..yMax) {
            for (x in xMin..xMax) {
                with (tiles[index(x, y)]) {
                    if (!mine) {
                        place(x, y, copy(adjacentMines + 1))
                    }
                }
            }
        }
    }

    /**
     * Reveals a tile at the given coordinates according to the game rules.
     *
     * @throws IllegalArgumentException if the X coordinate is outside
     * the range of [0, width), or if the Y coordinate is outside the
     *  range of [0, height).
     */
    fun reveal(x: Int, y: Int) {
        if (!valid(x, y) || !this[x, y].masked) {
            return;
        }

        with (this[x, y]) {
            place(x, y, copy(masked = false))

            if (!mine && adjacentMines == 0) {
                val xMin = (x - 1).coerceAtLeast(0)
                val xMax = (x + 1).coerceAtMost(width - 1)
                val yMin = (y - 1).coerceAtLeast(0)
                val yMax = (y + 1).coerceAtMost(height - 1)

                for (y in yMin..yMax) {
                    for (x in xMin..xMax) {
                        reveal(x, y)
                    }
                }
            }
        }
    }

    override fun toString() = buildString {
        for (y in 0 until height) {
            for (x in 0 until width) {
                val tile = this@Grid[x, y]
                append(when {
                    tile.masked -> "."
                    tile.mine -> "M"
                    tile.adjacentMines == 0 -> " "
                    else -> tile.adjacentMines.toString()
                } + " ")
            }
            append("\n")
        }
    }
}

fun main(args: Array<String>) {
    val grid = Grid()

    for (i in 0 until 9) {
        val x = (0 until 8).random()
        val y = (0 until 8).random()
        grid.reveal(x, y)
        println(grid)
    }
}

And just within the first line, we're introduced to a feature that provides massive gains in readability over Java. Data classes.

data class Tile(val adjacentMines: Int = 0, val mine: Boolean = false, val masked: Boolean = true)

In Java, if you want to group a few related values together, you'd probably write a full implementation of a class with "getter" and "setter" methods, and potentially other methods for things like testing for equality. That's a whole new file (assuming that you want to use this structure between classes) and several lines of code for something that should really be expressed in one line. Kotlin allows for structures to be declared this way. Here, we define a Tile structure, which acts as an immutable container for the information we want to associate with a tile in the Minesweeper grid. The compiler automatically derives methods to check for equality (equals), to create a unique hash code (hashCode), to provide a string representation (toString), and to make a copy of the structure. That last point on making copies brings me to another feature of Kotlin that makes programming with immutable data structures a breeze: named and optional parameters. Notice that there are default values in the above declaration – adjacentMines is 0, mine is false, and masked is true. If I wanted to create a tile that was a mine, but was still masked, I could simply call Tile(mine = true). Java only supports positional overloading, so in Java, it would be new Tile(0, true), assuming that I had an overloaded constructor with a default masked value. Returning to the point on the automatically-generated copy method, the named and optional parameters really shine here. Take a look at how it's used in the reveal method:

with (this[x, y]) {
    place(x, y, copy(masked = false))

I should probably explain the with statement to fully unpack what's happening here. with essentially allows us to run a block of code in the scope of an object. copy is a method of this[x, y], but we don't need to write this[x, y].copy since we are in the class scope of Tile (the type of this[x, y]).

The code for initializing a new Grid object does a nice job of illustrating Kotlin's ranges.

for (i in 0 until mines) {
    val x = (0 until width).random()
    val y = (0 until height).random()
    placeMine(x, y)
}

Kotlin is similar to Python in that there are no longer C-styled for loops (initialization + condition + afterthought). Instead, there are iterator-based for loops, and enumeration is done with ranges. a..b represents the range of integers from [a, b], and a until b represents the range from [a, b). Ranges are also objects, which is why we can write something like (0 until width).random(), which picks a random integer in the range [0, width).

Another big feature is type inference, which eliminates another pain in reading and writing Java. Take this facetious example:

InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState myState = new InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState();

The class name shows up twice on the same line, which I personally think is absurd. Is the type of myState really not obvious from the rvalue?

val myState = InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState()

Ah, much better. Of course, sometimes variables need type information, such as in the case of function parameters and return values. Actually, the type of a return value can be inferred, too. This can be seen in the definitions of index and valid.

private fun index(x: Int, y: Int) = y * width + x
private fun valid(x: Int, y: Int) = y in 0 until height && x in 0 until width

Functions can be written this way if their body is a single expression, and the compiler can infer the type of the return value from that expression. Expressions are a big thing in Kotlin. if is an expression (which you can see in the implementation of get), much like it is in Rust, as is when – Kotlin's replacement to Java's switch (which is sadly lacking in the way of pattern-matching). Assignment, fortunately, is not an expression like it is in C and Java.⁵ Here's an example of when used as an expression:

override fun toString() = buildString {
    for (y in 0 until height) {
        for (x in 0 until width) {
            val tile = this@Grid[x, y]
            append(when {
                tile.masked -> "."
                tile.mine -> "M"
                tile.adjacentMines == 0 -> " "
                else -> tile.adjacentMines.toString()
            } + " ")
        }
        append("\n")
    }
}

This is yet another example of a function body being written as a single expression. buildString is a function in the Kotlin standard library that takes a lambda as a parameter,⁶ executes it in the context of a Java StringBuilder, and returns the result of building that string. Kotlin provides a number of facilities to make working with strings more pleasant, including string interpolation:

val myNum = 7
return "myNum is ${myNum}" // --> "myNum is 7"

One last feature from the example above – Kotlin supports operator overloading. I'm sure that there was some rationale behind omitting operator overloading from Java, but I'm a proponent of languages that offer support for it. Where the operator overloading occurs in the example might not have been obvious, though.

operator fun get(x: Int, y: Int) = if (valid(x, y)) {
    tiles[index(x, y)]
} else {
    throw IllegalArgumentException("Invalid coordinates (${x}, ${y})")
}

get corresponds to the indexing notation, which is why this[x, y] has shown up a few times in the code. Yes, the indexing notation can take multiple parameters. The names that Kotlin associates with different operators tends to draw parallels with the conventions of the Java standard library. In the case of get, this means that you can use indexing notation on a Map. Pretty neat.

There are a few other features that I think are worth mentioning, but don't appear in the Minesweeper example.

val myNum: Int? = null

if (myNum != null) {
    println("${myNum + 4}") // myNum has been casted from Int? to Int at this point.
}

var value : Int? = null

fun F() : Int {
  if (value != null) return 0
  return value // Compiler error: "Smart cast to 'Int' is impossible, because 'value' is a mutable property that could have been changed by this time"
}

var value : Int? = null

value?.let {
    it.something()
}