What I Learned from 700 Hours of Kotlin

While I was working on Kray, I crossed 700 hours of work on Kotlin. This post will be about my thoughts about the language.

For reference, I started with Kotlin all the way back in 2020 to 2021. Which means I started during prime pre-GPT days before I had Copilot fix all of my bugs for me. It was really fun learning about the language and all it had to offer.

My first project was PlasmaEnchants, a Minecraft plugin with custom enchantments. It was a good starter project that helped me grasp and eventually come to love the language. Now, what will be five years later, I've absorbed myself into the Kotlin community on pretty much every major front. I did some Android and Web development with the Combinatory Game, some Kotlin/JVM single repository projects like with benchmarks, some Kotlin/Native stuff with KNCR and Kray, some Kotlin/JS stuff with @earth-app/ocean and @earth-app/shovel, and some Multiplatform stuff with TabroomAPI. Maybe I'll finish kasciffy at some point as well.

The Good

Kotlin is a good programming language. It's comfortable, lightweight, and easily extendable. Good languages should emphasize the developer experience as much as possible, in my own personal opinion. It's why I've never really clicked with C++, and more so stick to C. Same for why I tried to get into Go but couldn't really adapt to the new syntax. I started out with the C family languages like Java and TypeScript, so Kotlin was a nice touch for me.

I've written about this before, but Kotlin Multiplatform is extremely powerful. I think JetBrains is slowly starting to realize the potential of a language that can interop with both a virtual machine, native code, and client code. It's something I've tried to explore and extend with, which is one of the primary flaws that I'll get to later.

The other major good point that I think Kotlin has is its documentation. While there are some improvements to be made (again, I will mention later), the documentation overall is good. I know there is this sentiment for the developers of a language to document things themselves, but I think the fact that the Kotlin Foundation is primarily sponsored by a company that makes over $722 million dollars a year is a reason for them to at least try and keep the documentation correct.

The Bad

"Bad" sounds bad. There aren't really bad things about Kotlin. A lot of languages have bugs in them, and Kotlin is no different. I just don't think a major bug that I reported six months ago should still be in development, especially by said multi-million dollar company. But I can't really blame them.

One of the pitfalls of Kotlin is that it is still a new language. It wants to do a lot of stuff. To kind of emphasize this point, let's list some of the features of Kotlin:

• Work with C and C++
• Work with JavaScript
• Work with Java
• Work with Android platforms
• Work as a server backend
• Work with AI models in embedding and training

This means that you could, with enough effort and hacks, write:

• The entire Kotlin toolchain in Kotlin
• A C compiler in Kotlin
• An operating system in Kotlin
• The source control for that operating system
• A recreation of Minecraft on the operating system
• A browser for that operating system
• A webpage displayed on that browser
• A server powering that browser
• The firewall security for that server
• A dashboard to control the firewall security
• An AI to summarize and present the information from the dashboard

all in the same language.

The more features you add, the more bugs you will get. That's just how software is. Just like how giving out more food can get more people sick. This also goes back to the documentation point I've made earlier; it's pretty big and sometimes misses a lot of updates. I would say the page I look at the post is the documentation for the C interop file, since that has been where a majority of my projects lay in, post-Minecraft dev. The page is informative, for the most part, but as of writing this, it's missing a lot of advanced setup details that I had to figure out myself. For example, it turns out that the filters like headers.osx or linkerOpts.macos_x64 point to an enum of either the OS family or target type. Would have been really helpful when I was trying to figure out KNCR.

Another minor gripe I had was the fact that JetBrains seemed to be really stubborn about providing support on anything that wasn't IntelliJ. A couple of unofficial plugins tried to add support on VSCode or Eclipse, but they never were on the scale that IntelliJ provided. They caved in May to create a VSCode Plugin, but like most things in Kotlin, it's new and likely will need a few more years to mature.
This is also linked to a previous language I've worked with on The Earth App, that there is a consequence to prioritizing an enterprise feel over an open-source feel. Rust is one of the most loved by developers because it's open source first. That may be an oversimplification, but it's still a major reason. TypeScript is also one of the most loved, and it's backed by Microsoft. It's just two different kinds of programming languages. The multi-million dollar funding could be incorporated with more developer say to make the overall DX better. Kotlin being backed by JetBrains isn't a bad thing, nor is Java being backed by Oracle. They both work, and a mix can be even better.

These highlight the only problems I have with Kotlin. I've given up on a lot of projects, both side and main, because I had to wait for forever to get an issue fixed, or fiddle through a bunch of enterprise stuff. No hate to any individual or entity. Just the reality of shiny, new languages, I guess.

The Hope

I think Kotlin will go far. I also think JetBrains could spend more time putting effort into the Kotlin open source community instead of whatever AI stuff they're doing or trying to compete with our goat VSCode. Sounds like common criticisms of a corporation, I guess.

I mostly say that because the subset I spend the majority of my time in, Kotlin/Native, hasn't really seen any kind of significant improvement. There's no Windows ARM target, you can't use the toolchain on a Linux ARM machine, and the whole tool kind of feels strung together so that your average junior dev can just do the same thing every time. Looking through the Compose Multiplatform code can kind of show this, though they did put a lot of investment in Android and JVM interoperability. Because JetBrains controls a significant majority of what happens to Kotlin, I hope they clean up those loose wires in the next few years. Especially as Kotlin begins to weave itself into more and more infrastructure.

I'm excited for the future of the language. I love Kotlin to death, and I hope it continues to grow as much as it does. Add some minor tweaks and bug fixes and maybe we'll see it beat even Python one day.