How Kotlin makes me a more productive software developer

I’ve been writing JVM code for more than seven years now, and I did so mainly using Java. This changed about two years ago when I picked up Kotlin. By now, I managed to drop the Java language more-or-less entirely in favor of Kotlin. I did this because I feel much more productive with the language. It lets me focus more on the business logic rather than forcing me to write boilerplate code over and over again. In this post, I tell you how Kotlin makes me a more productive developer.
I certainly know Kotlin much better than I ever knew Java. FWIW, I had been certified as a Java expert by Oracle some years back. Still, Kotlin became my native programming language, and I want to encourage you to consider it too. When I talk about my Kotlin productivity, this probably is based on personal sentiment. I’m in a particular situation as I picked up the language rather early, right before 1.0 was released, and also worked as a teacher for the language ever since. Nevertheless, I’m convinced that some of the arguments in favor of Kotlin apply to many more of you, so let’s see what I’m talking about.

My JVM background

I used Java intensively for some years and wrote much productive code with the language. Java was my first language, and I did not know other languages too well at that point. Despite not having seen many other languages, I never really felt much joy when using Java, which changed when Java 8 arrived back in 2014. I immediately fell in love with the functional aspects that were added to the language and used lambdas and streams all over our code base. There might have been some situations in which I shouldn’t have done so, but it was bleeding Java edge, and I loved it. At that time, I started looking into other JVM languages and started to learn Scala at some point. I began by reading its documentation which was fun at first but then quickly started to become scary. I never really gave it a proper chance but looking back, I don’t regret putting it away after only a few weeks.

Kotlin

I don’t quite remember where I heard about Kotlin for the first time. The only thing I do remember is that JetBrains was mentioned along with it. I’ve always been a fan of their products, and so it was clear that I had to investigate the language they created. Other than Scala, Kotlin has a very digestible documentation, and it never got scary when I read it. I remember that I binge-read it in only a few days and there were like two topics I didn’t quite understand directly and bookmarked for later. One of those topics was backing fields, and the other one was probably related to delegation support.
Another thing that made it super easy to pick up Kotlin was the excellent support in IntelliJ. I learned the language with the IDE and the documentation. Another resource I totally recommend is the book Kotlin in Action which also helped me a lot with understanding the inner workings of the language better.

Standard Library

Kotlin has a fantastic standard library. If you think that Java also does, I can assure you that it is much weaker than Kotlin’s. You won’t need external libraries for everyday tasks like checking whether a String is blank or copying streams around. Kotlin provides all that and much more. It comes with an extremely sophisticated collections API, defines commonly needed extension functions on default types and finally gives the developer the option to add their own functions via extensions. You can find an excellent article on a bunch of standard functions here for example.

Feature-rich language

This one should be obvious. Especially when you’re coming from a language like Java, you will be blessed by the crisp features Kotlin provides. Think about null-safety, extension functions, easier generics or its catchy concurrency means provided by coroutines for instance – they all make us more productive and make the language more enjoyable.

Kotlin is intuitive

As a result of the fantastic standard library and the rich feature set, Kotlin is a very intuitive language. Frequently, you may try to perform some action on a given type and see what existing functions the IDE suggests. It then often happens that you find the function you were looking for already defined. Examples of this would be String::substringBefore, File::extension or Iterable::toSet.

Functional Style

When we talk about the standard library and also how intuitive the language is by itself, we also want to mention the functional aspects of the language. In this part, I particularly want to focus on functions. As you might already know, functions are first class citizens in Kotlin. You can declare variables holding them, pass them around and even return functions from other functions. You find lambdas (undeclared and directly passed functions) in every Kotlin code base. They are heavily used in the Kotlin standard library too. One example of this is the very helpful set of scope functions, which you can learn about here. Of course, lambdas are a vital ingredient to the collections API, i.e., stuff defined in kotlin.collections, as well. I can’t even tell how many times I use these functions in my day to day work. It somewhat gives me the creeps when I think about transforming collections within traditional for loops and how difficult it was to perform similar tasks in Java, especially before Java 8. Let’s see an example in action. Let’s assume we have some table/grid data modeled as follows:

Example

data class Grid(val rows: List<Row>)
data class Row(val data: List<Column<*>>)
data class Column<T>(val name: String, val value: T)

A Grid has multiple Rows which consists of multiple Columns. The task would be to calculate the totals for every given column identified by its name:

fun calculateTotals(data: Grid) = data.rows
    .flatMap(Row::data)
    .groupingBy(Column<*>::name)
    .fold(0.0) { accumulator, (_, value) ->
        accumulator + when (value) {
            is Number -> value.toDouble()
            else -> 0.0
        }
    }

Using functions from the Kotlin standard library, we can do the following:
1. collect all columns from all rows in a single collection using flatMap
2. group these columns by their name using groupingBy
3. accumulate the grouped columns by summing up their values

The above is just a single straightforward example that nicely demonstrates what you can do with the given collection functions. As I said earlier, I make use of these functions every day, I use it extensively, and I don’t want to miss it anymore.

You need to write less code

One of the most significant advantages of the functional programming style is the fact that you have to write less code overall. You make use of so-called internal iterations rather than specifying how to iterate a given collection explicitly. Loops sound easy at the beginning, and everybody should be able to apply them correctly. Still, they can easily cause hard-to-find bugs, which is a common problem of boilerplate code. The idea of functional APIs is that you can focus on the what instead of the how and thus don’t iterate collections explicitly but rather use functions like map, filter etc. which handle the iteration for you.

Less Boilerplate – Fewer errors in general

Boilerplate code can be the source of errors; naturally, the more code you need to write, the more potential bugs can be created. Since Kotlin removes the necessity for a lot of tedious boilerplate codes, the language makes you introduce fewer logic errors in general. An excellent example of this is the singleton pattern. Implementing it correctly is not as simple as you might think. You have to handle simultaneous access to singletons, which makes it hard to implement the initialization code of such an object. There are different approaches to this issue, all of which can cause potential issues if written manually. Kotlin, through its object construct, abstracts this for the developer and does not require you to write the recurring code every time.

Easier to debug and maintain

While in Java you have to spend much time reading and understanding boilerplate code, this is not that much of an issue in Kotlin for the same reasons already mentioned: a sophisticated set of features and a more concise language in general. Moving an existing Java code base to Kotlin reduces the code size by ~40% if done correctly. This, of course, makes Kotlin code much easier to read, debug and also maintain. To be fair, a rich feature set can easily be abused and may lead to hard-to-read code if used without care. So don’t write the code for you but the people who have to maintain it in the future.

It’s fun

All the reasons mentioned above make Kotlin a language that is fun. A pragmatic, concise and intuitive language is the best tool a programmer can think of, and you should not be using anything else. Having fun automatically leads to more productivity as well.

What you should do before calling yourself a Kotlin developer

I want to note that I consider it extremely helpful to know your toolset accurately. I took much time to learn Kotlin, primarily how it works and what features it provides, which everyone should do before writing serious Kotlin code. As a Java developer, you can quickly write compiling Kotlin code, but that’s still different from writing idiomatic Kotlin code. It won’t be sufficient to google for StackOverflow posts all the time. You should incorporate some fundamental techniques before getting started. I recommend studying the complete Kotlin documentation, which you can do in only a few days. On top of that, the book Kotlin in Action is the best resource you can find, and I highly recommend it.

Conclusion

Putting away Java in favor of Kotlin improved my programming skills and made me much more productive in general. I feel more joy, introduce fewer errors and feel less bugged than I did with Java. I don’t want to say that only Kotlin can do this for you too. However, maybe it’s time to get started with a more contemporary language to broaden your horizon and become more productive on the side.

The post How Kotlin makes me a more productive software developer appeared first on Kotlin Expertise Blog.