A strong Java developer, suspicious of Kotlin, challenged me with an interesting question, “What does Kotlin buy you at runtime?” It’s an interesting question because Kotlin runs on the JVM, what can it possibly do for you at runtime? This developer, with strong Java development skills, seemed to feel that any language running on the JVM, brought little if anything to the table if you really knew your Java. In a way I get that, but when you look at how distinctly some languages behave at runtime running on a common runtime, you know there’s more than just syntactic sugar at play. Scala and Clojure each have a distinct character from Java even at runtime. Elixir isn’t the same as Erlang at runtime.
So What Does Kotlin Bring to the Java Runtime?
These were my reactions.
- Null Safety. Sure it’s a language feature, but it will, at runtime, greatly reduce null pointer exceptions. Same runtime, different runtime behavior.
- Coroutines. A whole class of runtime issues in Java are avoided by coroutines. Thread safety and concurrency issues that can absolutely plague you with Java threading, can more easily be avoided with coroutines. I’ve written Kotlin code employing thousands of actors that ran stunningly from release one. Again, same runtime, but whole different nature at runtime. With Java that aggressively employed threading, I’ve literally spent days in Java runtime stack traces trying to sort out performance issues around data consistency and resource deprivation. Coroutines aren’t magic but I’ve never seen the same sort of runtime nightmares with them that I did with threads.
- Tail recursion. You can always unroll tail recursion yourself into loops, but using “tailrec” I’ve been able to write some elegant recursive code that was never going to stack overflow at runtime.
- Memory leaks. Kotlin’s more consistent code generation around functions and lambdas, and it’s emphasis on immutability, change the nature of memory use during runtime execution. Obviously they don’t eliminate memory leaks but I’ve never seen esoteric discussions about memory leaks like this one with Kotlin. Again, it’s the same runtime but the nature of the language greatly impacts the behavior of a running program.
I’m sure there are more, probably better, examples of how Kotlin behaves distinctly in the JVM, but I think I’ve made my point. You don’t have to change the runtime, to improve, through a language, how you utilize it.