From expected to actual: Kotlin doesn’t reinvent, it reuses 🔄

from-expected-to-actual:-kotlin-doesn’t-reinvent,-it-reuses-

A few days ago, I decided to dive into Kotlin. The reason? Work.
I knew Kotlin was based on Java, but to be honest, I don’t have much experience with Java. I haven’t used it in years, and even back then, I never really went deep into it. In recent years, my main focus has been Python.

I started playing with Kotlin by solving a few Leetcode problems and, being the curious dev I am, I wanted to check which methods IntArray had. I was working with that data type and expected to find a list of available functions directly in its definition, just like I’d do in Python with dir() or by checking a class’s documentation.

But that’s when things got interesting.

I opened the official Kotlin docs and noticed that methods like sort() weren’t defined directly inside the IntArray class. That felt odd.

After a bit more digging, I landed on the documentation for the sort() function and found this:

public expect fun IntArray.sort(): Unit

And I thought:

expect? What on earth is that?

I also noticed that in the different platform tabs (JS, Native, Wasm-JS, Wasm-WASI), it showed up as:

actual fun IntArray.sort()

But in the JVM tab, it didn’t. Instead, I found this generic version:

fun <T> Array<out T>.sort()

More confused than ever, I headed over to the Kotlin GitHub repository for some clarity. That’s when things started to make sense: I noticed folders like common, jvm, js, native, wasm, etc.
And then I remembered — Kotlin is a multiplatform language.

🧩 expect and actual: the multiplatform system

Digging deeper, I discovered Kotlin’s expect / actual system. The idea is simple, but really powerful:

  • expect declares a function, class, or behavior that should exist on all platforms.
  • actual provides the platform-specific implementation (JVM, JS, Native, etc.).

And here’s the part that blew my mind:

Kotlin doesn’t reinvent — it delegates

For example, the implementation of IntArray.sort() for the JVM platform is as simple as this:

public actual fun IntArray.sort(): Unit {
    if (size > 1) java.util.Arrays.sort(this)
}

💥 Boom! Kotlin didn’t write its own sorting algorithm from scratch. It just reused what was already in the JVM (Java).

And that makes total sense: Why reinvent the wheel when Java has spent years optimizing those functions?

What I learned from all this

  • Kotlin is multiplatform, but by default it runs on the JVM.
  • Many basic classes, functions, and primitives like Int, List, Array, String, etc., are delegated to Java.
  • The folders common, jvm, js, etc., in the Kotlin repo show how a shared API gets implemented differently per platform.
  • expect defines what should exist, actual provides the implementation per target.

So, if you’re working with Kotlin and you run into an expect, and you’re not explicitly using Kotlin Multiplatform, that implementation most likely comes straight from Java.

Final thoughts

Kotlin doesn’t reinvent the wheel. It reuses it, builds on top of it… and speeds up 🚗💨

As someone coming from Python, seeing this kind of design decision in a modern language felt incredibly elegant.

This was a great welcome into the Kotlin ecosystem.
And I’m just getting started.

Thanks for reading — hope you found this useful! Keep coding. 🖖
Thoughts? Let me know! 💬

✍️ Este post también está disponible en espñol – ¡dale un vistazo aquí! 🇪🇸

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post
iso-10012-revision-update

ISO 10012 Revision Update

Next Post
automated-calibration-systems-improve-manufacturing-accuracy

Automated Calibration Systems Improve Manufacturing Accuracy

Related Posts