is kotlin/native as stable as kotlin/jvm ?

https://kotlinlang.org/docs/components-stability.html#current-stability-of-kotlin-components

Kotlin/JVM

Stable

1.0

Kotlin/Native Runtime

Beta

1.3

Kotlin/Native new memory manager

Beta

1.7.20

Kotlin/Native interop with C and Objective C

Beta

1.3

alright 🙂

By default, Kotlin native only supports Kotlin and with cinterop C code. Sure you can use some compilers to convert java/jvm bytecode to native code or use JNI.

You mentioned LibGDX so I'm assuming you're doing game development. Kotlin/JVM will be much faster than Kotlin/Native for that. GraalVM (to my knowledge) isn't a good fit for games.

alright

Kotlin/JVM will be much faster than Kotlin/Native [for game development]

That surprises me - I thought the JVM was a fairly major drawback to game level speeds?

Kotlin/Native is relatively new technology, the JVM has 30+ years of optimizations behind it. Kotlin still has GC etc in all platforms

OK, I'd imagined that if you were using it for glue code and a C / C++ framework of some kind underneath via a facade it would be a reasonable gaming solution, interesting to hear not.

Well of course if all you do in Kotlin is a scripting façade, that's a different story

The JVM reputation of being really slow is extremely outdated

I know, there's no VM that has ever had the engineering put into it that the JVM has. My understanding is that it excels at use cases where it can take its multiple runtime cycles through some code to decide how best to optimise it, and the odd 100ms garbage collection isn't a big issue, like HTTP servers; and is not so good for use cases that want fast startup or cannot cope with occasional brief pauses, like games and command line interfaces.

Except the renderer, games are not real-time, and a 100ms garbage collection pause is completely fine.

For instance a year ago for fun I tried "Hello world" in multiple formats; a rust compiled version took 3.588 ms to run, a kotlin/native version 6.868 ms, and a JVM one 74.629 ms.

There are not really pauses nowadays. There are quite some games written in Java and also command line tools. There are even use-cases where a Java program runs faster than an according native program. You can in each language write bad and slow code or good and fast code. But yeah, if you need every nanosecond and every bit of RAM, you probably have to use Assembler anyway. 😄

100ms is also a very extremely worst case. A game like Minecraft (which arguably is one of the most successful 3D games of all time, and is also known for not being well optimized) runs pretty well.

I'm well aware of Minecraft, I've helped my son write extensions to it in Kotlin. But Minecraft's surely a paradigmatic example of how gameplay is more important than graphics in the success of a game, precisely because the graphics are objectively dramatically worse[1] than typical modern 3D games? Has anyone got an example of a top flight graphics & FPS dependent game that is deployed as JVM bytecode running on a JVM? I remember Il-2 Sturmovik used the JVM for the interface, but dropped down to C++ for the actual flying. I'd have thought if it were viable it would be an excellent idea, given Kotlin is streets ahead of C++ in terms of how much safety it gives you and how bug ridden games can be. [1] where worse means lower detailed, less lifelike - fine for its purposes, obv.

C++ does have coroutines now: https://en.cppreference.com/w/cpp/language/coroutines

@Rob Elliot The JVM isn't the target for top game engines. Neither is Rust (yet) or Go, or Swift, or Dart, or a host of other languages. And most of them never will be. There is more than games in the world.

The conversation was explicitly about game development.

@Rob Elliot that's a bit unfair, Minecraft has editable terrain which basically no other game has.

What does that have to do with its graphics?

But yeah the main issue against using the JVM for 3d games now is that JNI has quite a high cost, so you're better off implementing the renderer in C/C++ and doing only high-level game logic on the JVM. Maybe Panama will help with that, maybe not. Anyway my point was between Kotlin/JVM and Kotlin/Native, not between Kotlin/JVM and C++.

I thought system's people tend to not like java, is not because it is slow, because it is not, but because of the performance unpredictability (gc)

The performance is not unpredictable. It is even extremely configurable

well, is it? you dont know when memory is going to be freed

You might not know when, but you shouldn't care. I'm not familiar with all Garbage Collectors and choices maybe there is also some "more predictable" one. But there are serveral Garbage Collectors to choose from and with several options each if you really know what you do and need tweakage.

but this I believe is why spacex won't run java, they just cannot "risk" a gc

There is no risk in a proper GC o_O

okay I don' know, it's what I've heard, first there is jitting and stuff, sure you can solve that with AOT, but gc you cannot determine when it runs, and they need to know this memory is freed when this function returns/this other thing dealocates etc

As I said, they shouldn't care, that's what a GC is for. If they need to care, a language with GC is maybe not the right choice. But why should they care? And jitter I don't know, but can probably be eliminated by right choice of GC and its options.

but in system programming you do care, say self driving cars etc

Enumerating use-cases does not answer the question why they should care

because high performance applications care about predictability, they need to run the same way all the time, not sometimes randomly slower because of reasons, memory usage also differing etc, all hinges on how GC runs

Again, just because you have a GC does not mean anything is unpredictable or randomly slower

Why is android itself mostly written in c++ then?

Ask the ones that implemented it. Besides, what you need on Android is a JVM implementation and that is Dalvik and and JVM implementations themselves are often written in non-Java language afair. Maybe also back then there were not as many GC choices, GC evolved pretty much in the last years. Z GC e. g. is stable as of Java 15 or something like that.

It's mainly JNI interop which is unavailable Eg, attempting to completely rewrite skia in java with GL bindings would be a collosal undertaking and would serverly hurt any expectations of native skia vs JVM skia

try (=)

(java)/`.use {}` (kotlin) are the the lifetime scope of resources

Yea but more of resources that exceed try/use scopes