floverfelt.org

Me

Thoughts, notes, etc.

View the Site on GitHub

View my GitHub Profile

View my LinkedIn

Email

8 June 2023

Kotlin

by Florian

Kotlin: I’m still not impressed?

I’ve used Kotlin twice - once at my previous job as the language of choice for a new project and then again over the past week for a new side project I’ve been coding up.

I’m… still not impressed with it? Despite all the hype on HackerNews over the years it seems… just fine?

I remember picking up Node a few years ago and I could more or less instantly see the value add - the frontend and the backend are in the same language, it’s straightforward to read/write with optional typing with Typescript, and it’s fairly performant with a large ecosystem.

With Kotlin, I didn’t really have that moment at all. It seemed to have some neat features and allows more functional & flexible patterns, but that was really it. It did make me think, though, what do I value in a programming language?

Terseness is overrated

Let’s look at the (tired) joke about how verbose it is to run a method in Java:

public class Main {
	public static void main(String[] args) {
		System.out.println("Hello, World!");
	}
}

Vs. Kotlin

fun main() {
  println("Hello, World!")
}

Yes - Kotlin is shorter, easier to read, and easier to type. That’s a kind of nice benefit? But I have a lot of problems with the whole “which language is easiest to write a main() method in” debate.

First, programs do a lot of things beginners don’t understand. I remember the professor teaching us the whole static void main… thing and thinking - huh, ok those are the keywords to get the program to run. I didn’t care about what static or public or void or main or String meant because I was a beginner. I didn’t know what an IDE was but I was using that. I didn’t know what a compiler was! Or a programming language! Magic words that make things happen was more-or-less my understanding of programming, a few extra here or there was not the hurdle that was preventing me from learning.

Second, you don’t write this method all that much in professional development? I’ve been writing a CLI recently and that’s required quite a few main() methods, but before that I can count on (maybe) both hands the number of times I’ve really needed to write the full static void main… signature at work. In those rare cases, yes, it would have been nice for it to be shorter.

Third, terse languages often trade types for brevity. That’s a fair trade-off to make, but I feel like it negates any benefit of the whole “this language is easier to learn because the main method is simpler” argument.

SomeObject someObj = new SomeObject("value");

Is redundant to a professional developer, but to a beginner it’s much easier to read with the type on the left and the right. It’s just kind of funny that engineers roll out the main() example and then often omit what’s lost when you drop all those types. Types and objects are fundamental to programming - regardless of the language being static or duck - and introducing them early, even if they won’t be fully understood or treated as programming magic, is better than introducing them later.

But, hilariously, Java supports getting rid of the left handed types altogether if you want!

Finally, and this may just come down to personal preference, but is my life really all that much better off with fewer lines of code? Or without semi-colons? Do I care? I’m an engineer to build things. I don’t really care about the brevity of the code I type as long as it gets the job done in a reasonable way and:

public static void main(String[] args) {
  
}

Is not unreasonable to me? I dunno, I wonder what could have been built if JetBrains had just stuck with Java and built several new products instead of investing so heavily in Kotlin. Would Kotlin be missed?

What happened to Groovy?

Why is Kotlin loved and Groovy hated?

A lot of the surface level stuff people like about Kotlin… already existed in Groovy? It’s type optional, has a more concise syntax, offers alternate builder/constructor patterns for typical objects, is object optional in many places, has better String formatting, etc.

I have nowhere to go with this tangent other than to say that I had a much more pleasant experience with Groovy than Kotlin. It seemed to know what it was trying to do - be scripted Java with a nicer syntax - whereas Kotlin tried to do too much. It was simultaneously trying to be a superset of Java, but also functional, but also 100% cross compatible with plain Java.

This led to a lot of situations where I had to think:

  1. How would I do this in Java?
  2. How do I do the same in Kotlin?
  3. How do I take code samples from some documentation and translate them into Kotlin?
  4. Is the code sample or dependency actually compatible with Kotlin?
  5. Do I like the new syntax better? Is it doing the equivalent thing?

The rich library of mature dependencies is one of the core selling points of Java and I really did not want to grapple with step (4) every time I used a dependency or (3) every time I had to integrate a library.

I never quite got to the point where I could just write Kotlin. I felt like I had to write Kotlin and Java at the same time - understanding the nuances of both.

Some closing thoughts…

I feel like programming languages that compile to the JVM are a neat idea, but they don’t quite do it for me. If I’m on the JVM, I’d rather use Java. It’s there, I know it, and it just works. The functional/syntactic stuff doesn’t bother me and I’m familiar with it enough that a lot of the other “problems” with it are part-parcel of the bargain.

If I wanted a “cooler” langauge, I’d migrate off the JVM altogether and use something totally different that isn’t trying to do everything-and-the-kitchen-sink with Java.

tags: posts - coding