How Kotlin makes me a more productive software developer

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.

Please follow and like this Blog 🙂

8 thoughts on “How Kotlin makes me a more productive software developer

  • Jan Vladimir Mostert

    Same, i put Java away for good end of 2016, never looked back
    Java8 made me investigate other languages too, actually Dart more so which was already an improved Java8 syntax and somehow i came across Kotlin and just got hooked immediately, even though the null-safety was awkward and many of the functional concepts took a bit of time to get used to.

    Looking forward for multiplatform to become more mature, KotlinJVM, KotlinJS and Kotlin on Android are already awesome, it finally feels like i’m actually solving business problems instead of getting bogged down by null checks and other boilerplate.

  • Peter

    A lot of what you’ve listed here is already present in .NET, and has been for quite a while. I’ll never really understand the industry obsession with Java, and until someone makes a really definitive argument as to why it’s still being used, I’m just going to assume that it’s because a lot of legacy things are in Java, and that developers (and managers) don’t want to invest the time or money into switching platforms, especially from IntelliJ to Visual Studio.

    Maybe I’m wrong and Java is a great language – but I’ve been able to write RESTful services using ASP.NET with about half the code as would be used in an equivalent Java – based service.

    • Java is not a great language but the Java Virtual Machine is a fantastic platform which has been adopted widely and comes with very sophisticated tools and frameworks. I also think that, language-wise, that C# is much nicer than Java. It definitely would not be an alternative to Kotlin for me. Don’t @ me 🙂

    • Martijn Vos

      No, Java is not that great. JVM is great. Java is merely everywhere. It was better than what existed before it, and in the JVM, it provided a stable yet flexible platform to develop on. But Java the language is way too verbose, and is encumbered by the legacy of a number of bad decisions. A new JVM language that interacts painlessly with existing Java code would be an excellent idea.

      In the past I hoped that either Groovy (nice, but too slow) or Scala (fast, gorgeous, but occasionally horrifying) were that excellent idea. I haven’t worked with Kotlin yet, but it sounds like it might be that perfect middle-ground between Java, Groovy and Scala.

  • Hey, thank you for sharing your own feelings and experiences with Kotlin language!

    I love all the things you already mentioned:

    intuitiveness of Kotlin,
    feature-packed useful standard library,
    functions as a first-class citizen without scala-like overcomplication)
    less boilerplate: I can focus on the business logic instead of irrelevant details,
    focusing more on “what” instead of “how,”
    it’s much more fun (I came originally from non-java langs like Python, Ruby, Scala, and Clojure, so I feel “at home” when programming in Kotlin).

    On top of that, I’d like to mention the following specialties of Kotlin that make my life simpler:

    bi-directional interoperability with the JVM ecosystem, which allows me to use mature libraries and frameworks;
    type inference (not only for local variables): this allows you to choose when you want to specify more type details in your code and when you want them to be hidden because they’ll be just noise from reader’s perspective;
    immutability is a default modus of operandi: “val” is the default option before you upgrade to “var” only when necessary, “listOf” is the default option before you upgrade to “mutableListOf” only when needed;
    rarely used DSLs for very special problems (and for libraries);
    combination of named parameters and default argument values is very useful to both reduce duplication and make calls very readable, and let them focus only on what’s important to the reader;
    smart-casting after any type check which allows you to not repeat yourself with a direct typecast (or nullable unwrapping): in other typed languages, this is a quite annoying problem, and Kotlin solves it gracefully;
    last but not least, while Kotlin is a concise language, it doesn’t go all the way (like Scala or some others), instead, it finds a very good balance where it’s concise enough to let developer maximize the readability of the code, and not stand in the way of doing that. If it was too concise, or not concise enough, it would make it more challenging to write readable code and focus on business logic.

    After I worked on Kotlin for 2 years, I had to go back Java project with no chance of Kotlin conversion (circumstances, don’t ask!), and it was so much pain to work with streams, optionals and boilerplate—it was driving me crazy and very upset.

    I’m looking forward to more global adoption of Kotlin on Backend.

Leave a Reply

Your email address will not be published. Required fields are marked *