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