Kotlin native can only use other libraries that su...

# kotlin-native

[asad.awadia]

Kotlin native can only use other libraries that support native right? I.e i cant kotlin native a vertx application?

[Jeremy]

Correct, if developing a server side app that means will not have access to JVM libs like JDBC either

[asad.awadia]

Oh wow - would that not make it super limited?

[asad.awadia]

Is there a list of libraries that can be used?

[Jeremy]

Yes, I think the primary use cases are client side like command utils and mobile apps

[asad.awadia]

Oka thanks

[Jeremy]

Not sure of definitive list of libs but there is libs support for json, concurrency, persistence and stdlib which meets my immediate needs (mobile dev)

[asad.awadia]

How would you even use it client side tho? Lets say you have a native binary - how do u even bring it in to ur app?

[kpgalligan]

Primary use cases now. I think the idea is rather than carry around the “VM” portion and attempt to support existing Java, the goal is for libraries to be created as needed and designed for stdlib kotlin. I’ve seen server side discussed as a goal, although that would be difficult now.

[kpgalligan]

For iOS, the compiler creates a framework and your “native” code talks to it like any other framework

[kpgalligan]

For the JVM, it’s just like other kotlin JVM interop.

[kpgalligan]

So, for iOS, if you’re using Swift, the Swift code thinks it’s talking to Objective-C. The kotlin compiler creates an Objc header (and implementing binary).

[Jeremy]

Its an interesting question. I've always thought of graalvm+kn to be solving different types problems

[Jeremy]

If you find a common use case and benchmark them post the results 🙂

[kpgalligan]

We’ll see how things go. I’ve never done anything with graalvm. I can see where that eats up a lot of the compiled server side, but there have to be some tradeoffs involved too. Binary size, etc. For today, it’s mostly just client side for Kotlin native. Server side is JVM

[Jeremy]

afaik graalvm sacrifices runtime perf for startup time, primary use case is faas

[Markus Böck]

You just have to less rely on the JVM library ecosystem but rather on the kotlin native or any other native language library(like C, C++, Rust, Go, ObjC, Switft and so on)

[napperley]

Speaking of client side native GUI client apps should be added to the list of primary use cases.

[napperley]

Especially native Linux GUI apps. Developed a poor clone of Gedit (called KPad 😆) a while back, which works well performance wise (reserves around 5.5 MB RAM, binary size is around 700 KB, and the program starts up in ms when run on PC running Linux Mint 17) from a perception POV. Can find the KPad project here: https://gitlab.com/napperley/kpad

[corneil]

If did some benchmarks comparing various options at part of this: https://speakerdeck.com/corneil/kfsm-a-kotlin-dsl-for-finite-state-machines

[corneil]

Graal Native outperforms Kotlin Native by a large margin. JVM JIT as in Hotspot or GraalVM outperforms everything else by a mile

[napperley]

In that particular use case yes, however in some use cases like GUI/CLI client side apps the performance outcomes would likely be reversed (Kotlin Native performs better than GraalVM/JVM).