Kotlin-JVM will cost you several seconds on each startup if you do not use daemon.
As we discussed earlier, there is no critical difference between Go and Kotlin-Native. So you can choose whatever you like best.
Thanks. So just to confirm, Kotlin/Native in its current beta state is production-ready enough for those two applications (ex: Terminal UI library support)?
Yes, it should. The only thing that is not stable yet in native is multi-threading support without freezes.
Thanks for the clarification! Glad to hear it’s production ready now.
A third alternative for native solution is Rust. Usually the argument is Rust vs Go rather than Kotlin Native. The argument usually goes that Go is better for unstructured things and has lower learning curve and Rust is better for planning in higher detail on larger projects or high performance tools. In my opinion Kotlin Native and Rust ecosystems would benefit at many levels if Kotlin Native was re-done in Rust. Rust already has strong foundation and community for FFI bindings (interacting with C and Objective-C), LLVM, web assemblies, etc… Even the Kotlin Native garbage collector could be abstracted out to a generic Cargo Crate. It would probably lead to elegant interoperability of Rust and Kotlin source code in projects too. Another thing, Kotlin and/or Kotlin Native projects “usually” use Gradle and that in itself is motivation to use something else (IMHO).
1 Like
I agree, gradle and JVM are the most reasons why is hard to convince non-java developers to use/learn kotlin, kotlin is a ‘java’ language, and that holds it back, a lot of languages came and died when Java itself improved because they were ‘java’ languages, like groovy and scala, and now with java 21, it will be hard to convince java developers to use kotlin.
That why i believe that kotlin has to have something special.