Kotlin

6 min readSep 20, 2015

my productivity language

There are a lot of programming languages out there and I, for one, like to explore them. For me exploring is usually reading the docs, following the getting started section and fiddling around with some language constructs. Sometimes even recreating a small library that I have recently created in some other language.

Yet those languages hardly ever make it to my default toolbox. The reasons for this are naturally diverse but at the same time some of those reasons emerge more often than others. The size and quality of the community is one of those reasons. The fact that there a many libraries and frameworks that help me solve common problems and furthermore the drive and passion of the people behind that software, matters greatly to me. Another is that some languages introduce a complete shift in paradigm. I don’t mind altering the way of doing things but you have to get other people along and that simply isn’t always an option.

So at the end of the day I tend to fallback to that what I already know, which is Java, C# and JavaScript. Great communities with great support and a lot of building blocks for the taking. It is therefor only logical that I look at the languages that compile to these platforms with increased interest. Those particular languages have the potential to leverage already large communities.

One of those languages is Kotlin. This a language that is being developed by JetBrains, the company behind the popular IDE IntelliJ IDEA. So the IDE support is really first class. Kotlin targets first and foremost the Java Runtime Environment. With version 1.0 in sight all effort now goes to polishing the language. After that the already supported JavaScript platform will get more attention.

Features

I want to talk about features. Kotlin’s features. So I could sum up all the language features and how they compare to other languages, but I won’t. I think that is a fruitless endeavour. I will talk about how I feel the features of Kotlin came about and what I find refreshing about this particular language.

A lot of languages seem to be born out of form of frustration with some other language. Though that might be the case for Kotlin too, I feel the guys and girls at JetBrains still recognise Java as a great language. But Java, like any language that is ageing, adding features and refining the language becomes harder. You can only change the language to a certain extend to remain backwards compatible. So Java isn’t wrong, it’s just ageing and sometimes it shows. Wine ages too.

What Kotlin does is take the experience we have from Java and other languages and try to improve upon the lessons learned. You only have to skimm through a couple of forum or blog post from the JetBrains team to find quotes from “Effective Java” or works of the like. It’s reality put in a language, not academia.

One of my favourite gems is the way Kotlin handles `null`. Yes, it does handle `null` as you would expect from a language that’s just compatible with Java. It just handles it in a smarter way. Take for instance a typical Java method:

public void foo(Bar bar) { /*…*/ }

Now there a plenty of cases where we have absolutely no sane way of handling `null` if that is passed into this method. So the sane thing to do is to check the input:

public void foo(Bar bar) { 
  if (bar == null) 
    throw IllegalArgumentException(); /*…*/
}

Now that’s better. At least we get an exception, with hopefully an informative message, that tells us this method can’t sanely handle `null`s. But that’s only runtime so we’re not in the green just yet. It would be even better if we could inform our colleagues of our intent that we don’t want any `null`s in there. So we improve even further:

public void foo(@NotNull Bar bar) { 
  if (bar == null) 
    throw IllegalArgumentException() /*…*/
}

We’ve improved our example even further with expressing our intent that `null`s aren’t allowed. Tools like IntelliJ IDEA detect on the call site that you might pass a `null` to a method that can’t handle it and informs you about it, great! There’s nothing wrong with this code, it just a bit verbose for the intent we tried to express.

So along comes Kotlin which deals with `null` a bit differently. What Kotlin does is it makes the distinction between nullable types and non-nullable types. Every type can be made nullable just by putting a question mark at the end of the type name, so `Bar` is non-nullable and `Bar?` is, simple as that. Our previous Java example can be rewritten in Kotlin like this:

public fun foo(bar : Bar) { /*…*/ }

In all fairness this example isn’t exactly the same code because it lacks the `null` check of the Java variant that might throw the exception. But the thing is, we don’t have to. The Kotlin compiler makes sure that no `null` can go in this function as such attempt simply won’t compile.

Now I can go on about all the smart things that happen on the call site concerning `null`s, but like I said earlier, I’m not in the business of doing some feature comparison. My intention was to demonstrate how Kotlin tries to improve upon the lessons learned from years of actual projects.

Conciseness

The previous example hinted towards the topic of conciseness. It often goes hand in hand with another common term heard in language design, expressiveness. I usually find this kind of topics not that important, or at least not with the common outcome they usually have. Way to often discussions about these topics end in some battle trying to smack as much information as possible into one line which is then littered with a plethora of incomprehensible operators. That might be concise, granted, but it sure as hell ain’t expressive.

To me, the most important thing about expressiveness, and luckily it’s how most people I’ve come to know explain it, is about expressing intent (once). It’s most certainly not about being as concise as possible, that’s merely a positive side effect. It’s much more about readability. So how well is a piece of code explaining to another developer the intent of the code?

I’ve got the feeling, and I can’t objectively state this, that Kotlin is hitting near the sweet spot of expressiveness. The code remains fairly readable for the novice Kotlin developer yet powerful enough for the experienced one.

Interoperability

As I stated before the ability to leverage the works of an existing community is important to me. This is where Kotlin really shines. The interoperability with Java is just marvellous. Not only can you call Java code without any need for facades or other intermediate logic, you can also call Kotlin code from Java just as easily. At the risk of being sued by a large fruit company I have to say: “It just works”.

The interoperability goes even further then only being able to call Java from Kotlin and vice versa. Kotlin and Java files can be freely mixed. So even existing projects can leverage from Kotlin, it doesn’t have to be an all or nothing solution. So that well tested and highly invested piece of core code can just remain the same.

Kotlin runs on Java 6 and that is great news for Android developers. Android developers seem to miss out on all the improvements Java has gone through over the years and most notably with Java 8's lambda expressions. With Kotlin Android developers get things like lambda expressions right now!

That’s why

So I hardly covered any Kotlin specific feature, but if you’re interested you can read the docs or fiddle around online. I mainly wanted to show why I like Kotlin in a way other than just sheer language features. It’s the focus on productivity that really reels me in. No real paradigm shift, but mainly compatibility. Kotlin is my new weapon of choice.