Being productive with modern programming languages, by a software engineer who has been using Kotlin for over 5 years
I’ve been writing code for the JVM for more than 10 years now, many of those using Java. This changed about five or six years ago when I picked up Kotlin. By now, I managed to drop the Java language completely 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 will share my top 8 reasons why Kotlin makes me a more productive developer.
I certainly know Kotlin much better than I ever knew Java. For what it’s worth, 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 is mainly based on personal sentiment and not backed by actual data. 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.
I used Java intensively for some years and wrote a lot of productive code with the language. Java was my first language, and I did not know other languages very well at that point. In the meantime I have been exposed to many different programming languages such as TypeScript, Go, C#, Swift, and more.
I never really felt much joy when using Java, which changed a bit with the arrival of Java 8 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. Of course, this wasn’t always appropriate.
Yet, 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.
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, so it was clear that I had to investigate the language they created.
Other than Scala, Kotlin comes with fairly digestible documentation, and it never felt scary reading through it. I remember binge-reading it in only a few days. Only two topics weren’t understood immediately so I bookmarked those 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 immensely helped me understand the inner workings of the language.
Kotlin has a fantastic standard library. 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 member functions via extensions. You can find an excellent article on a bunch of standard functions here for example.
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 coroutine for instance — they all make us more productive and make the language more enjoyable.
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.
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. 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. I shiver thinking 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. We assume we have some table/grid data modeled as follows:
Grid has multiple
Rows which consists of multiple
Columns. The task would be to calculate the totals for every given column identified by its
Using functions from the Kotlin standard library, we can do the following:
1. collect all columns from all rows in a single collection using
2. group these columns by their name using
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 them extensively, and I don’t want to miss them anymore.
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 almost everybody can apply them correctly. Yet, loops can easily cause hidden 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
filter etc. that handle the iteration for you.
Boilerplate code can be the source of errors; naturally, the more code you need to write, the more potential bugs are introduced. With Kotlin removing 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 declaration, abstracts this for the developer, and does not require you to write the recurring code every time.
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 applied with too little care. Don’t write the code for you but for the people who have to maintain it in the future.
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.
I want to note that I consider it extremely helpful to know your toolset accurately. Of course, the following can be applied to almost every topic out there and it’s just my personal opinion. For other people, it might work differently.
I used a lot of time when learning Kotlin. I looked into how it works and what features it provides and recommend everyone else to do the same 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.