Introduction

This Kotlin version of my exercise server “Simple Server” is now the sixth language that I have used to implement the same server as an exercise (previous implementations: Clojure, Javascript, Java, Python and Go, see: my previous blog post regarding these exercises: Five Languages - Five Stories. I’m planning to implement the Simple Server also using Typescript — maybe after that implementation I update that blog post to “Seven Languages - Seven Stories” :-).

You can find the project in Github.

Once again I tried to replicate the file/namespace/class names so that it is easy to compare the implementations (e.g. server.kt — server.py — server.js — server.clj — Server.java — server.go).

Kotlin Code in IntelliJ IDEA.

Tools

I used the following tools in this exercise:

Kotlin vs. Java

I actually started to learn Kotlin already some four years ago. But after a short introduction I thought that “Kotlin is just Java done right” and decided to deep dive into Clojure instead (which actually was a good decision — Clojure is an excellent language and very different when compared to Java and Kotlin). But this autumn I was “forced” to deep dive to Kotlin as well: I worked this autumn with an interesting customer which had a team of extremely competent developers who were also a bunch of real language enthusiastics. They had implemented many microservices using different languages, one of the languages being Kotlin. In that assignment I had a chance to convert one old Java application to Kotlin. Therefore I had a good reason to learn Kotlin and I also decided to implement my exercise server using Kotlin.

After doing some diving into Kotlin I realized that Kotlin actually is much more than just “Java done right”. Kotlin is a very well designed language and you can use Kotlin quite naturally either using object-oriented paradigm or using functional paradigm. I decided to implement this Kotlin version of Simple Server using functional paradigm to compare this side also to Clojure.

My main impressions regarding Kotlin as a language are:

  • Kotlin is really easy. If you have used Java you have absolutely no issues to learn Kotlin. Kotlin has actually simplified creating backend systems using a JVM language quite a bit compared to Java.
  • Kotlin is pretty concise. Example: data class User(val email: String, val firstName: String, val LastName: String, val password: String), i.e. you have a valid data class ready to be used without any Java getter/setter boilerplate. Since Kotlin is both easy and concise new developers will be productive in a short period of time.
  • Expressions. I really liked Kotlin’s idea that most of the things that are statements in Java (if-else, try-catch…) are expressions in Kotlin (i.e. you return values from those constructs) — this idea supports a lot using Kotlin as a functional language.
  • Mixing Java and Kotlin. You can mix Java and Kotlin files without any extra boilerplate in your project. This makes migration from Java to Kotlin extremely easy: just convert the files one at a time as a need basis. I also tried IntelliJ IDEA’s Java-to-Kotlin migration tool and it was astonishingly good — there were only a few cases where the tool couldn’t figure out how to do the conversion. See: Mixing Java and Kotlin in one project in Kotlin documentation.
  • Null pointer safety. Kotlin provides language constructs to avoid most of the null pointer exception errors. See: Null Safety in Kotlin documentation.
  • IDE tooling. IntelliJ IDEA is a great Kotlin IDE, of course since the same company — JetBrains — is behind the language and the IDE. See: Getting Started with IntelliJ IDEA in Kotlin documentation.
  • Gradle and Kotlin. You can use Kotlin as a Gradle domain specific language (DSL). See: Using Gradle in Kotlin documentation.
  • Lesser need for exceptions. Kotlin provides nice constructs that you can use to pass information e.g. whether you have found results for some query or not using sealed class. See Sealed Classes in Kotlin documentation for more information. Example:
sealed class ProductsResult
data class ProductsFound(val data: List<Product>) : ProductsResult()
object ProductsNotFound :
    ProductsResult()

Then you can use these sealed classes quite nicely to process various happy-day scenarios and exceptional scenarios, example:

val ret = when (val products = getProducts(pgId)) {
    is ProductsNotFound -> ProductNotFound
    is ProductsFound -> {
        when (val p = products.data.firstOrNull { it.pId == pId }) {
            null -> ProductNotFound
            p -> ProductFound(p)
            else -> ProductNotFound
        }
    }
}

This makes code pretty readable: “If you didn’t find any products you cannot find an individual product. If you found products you can try to find an individual product by pId field.” Because when is an expression you finally return some value to variable ret.

Kotlin vs. Clojure

When comparing Kotlin to Clojure my first impression is however: “Kotlin is pretty good but compared to Clojure Kotlin is just Java done right”. With this statement I mean that Clojure being a Lisp has all the power of Lisp including a real REPL and a real functional language with immutability by default, and excellent data oriented language structures and standard library to process data. If I started a new project with competent developers who already know Clojure or are willing to learn it my choice of language would definitely be Clojure since with competent developers Clojure (Lisp) is like a secret weapon when considering developer productivity. But if Clojure is not an option and I had to choose either Java or Kotlin I would definitely choose Kotlin. So, considering JVM development I’m starting to think that there is no going back to Java. Sorry Java, you had your glory days but now it is time for new guys to continue the JVM journey.