Status of Kotlin/Native?

Hi all :wave:.

I mainly program in python, but I really like kotlin and have been dabbling with it for small things for quite a while.

I was wondering today about the status of kotlin-native, as I was unable to find an explicit statement on the kotlin website. Is kotlin-native still in beta? What are the drawbacks of kotlin-native today? I saw mention of performance improvements in some of the release notes, so it seems native got faster recently, does anyone have up-to-date information performace information?

Thanks in advance!

Kotlin-native is in beta and there is a lot of work done on a new memory model. It is usable and a lot of people use it, but there are some hiccups with concurrent programming.

But the real question is whether you need Kotlin-Native. There is a common misconception that kotlin-native is “faster” because it is “native”. It is not. Kotlin JVM is and probably will ever be better optimized save for very specific hardware optimized tasks. So if you want to go native for performance, don’t. Take Kotlin-JVM and be happy with it. If you want to use interop with native libraries, try jna, javacpp or other FFI wrappers, probably there are already java FFI wrappers for everything you need.

2 Likes

Hi @darksnake, thanks for replying!

I suppose kotlin native would still be a good choice for situations where I would like to execute code without shipping a runtime, where it is also not important to have the best performance. I don’t currently have such a use case, but I’m sure many exist :slightly_smiling_face:.

It is interesting to hear that kotlin-native will never beat Kotlin JVM. Is this because of the JIT? Or is this also due to design decisions of kotlin native?

The native executable is smaller indeed.Yet, you can still look in direction of jpackage and GraalVM native image (they are both still larger than K-N binary). I am not so sure it is worth it in a general case, but there could be cases where it is important. As I already said, it makes sense to use native when you have some kind of hardware specialization.

The average performance of native applications (and I do not mean only Kotlin Native) is not as good as JVM because of JVM JIT (and the amount of work put into it is hard to replicate) together with memory management. You can’t write effective modern application without some kind of memory management and,again, it is hard to replicate the amount of work put into JVM GCs.

Of course there are always systems programming fields, where you need manual memory management and manual hardware specialization for the code. There you should use special tools like Rust and maybe Kotlin Native (in future).

1 Like

Just wanted to point out that you probably don’t see as much about Kotlin “Native” as it really is just part of Kotlin Multiplatform which can build for JVM and Android using Java classes, for Javascript, and using Native for iOS, Android, MacOs, Windows, and Linux. The various targets are at differing levels of stability.

Here is a list of supported targets

2 Likes

Kotlin/Native already has its place. We use it for Localazy CLI - a command-line tool that is used by thousands of users in production without any issues.

We decided to use Kotlin because it allowed us to make the CLI tool available for our users in their preferred variant.

At the moment, we have a single code base with JVM, JS, and native implementation for I/O, HTTP, ZIP, and a few smaller things. All the logic and processing are written in pure Kotlin - in the common module. Typically, we don’t need to touch anything else than the common module when adding new features.

This way, we can build native Windows, Linux, and macOS binary, JVM, and JS versions. We make all these files available for download directly as well as through Brew, APT, YUM, NPM, Docker, etc. This helps us to cover all our users with a single code base.

As for drawbacks, it would be helpful to have more examples. We had to discover a lot of things on our own and it consumed more time. Also, there are still not enough libraries for Kotlin/Native, so we needed to wrap some of the native libraries.

We couldn’t use recommended Ktor Clients for the Windows binary because it would introduce too many dependencies, it was hard to link it statically and it led to a huge binary. So we write our own code using Windows’ WinInet API.

Also, it’s a bit painful to upgrade to newer Kotlin versions since it needs libraries to be recompiled.

However, I would recommend it for sure because once we have built the foundation, it’s a joy to improve the tool and add more features.

Wherever the JVM version is possible, I would go with JVM Kotlin. It’s definitely better, but as said in my first sentence, Kotlin/Native has its place and it’s an awesome tool already.

1 Like