Java had a native gcc front end way back in the 90's. No one used it and they eventually dropped it. This isn't really a killer feature for the problem areas targetted by Java developers.

Android ART is, effectively, a native compiler for a Java-targetted (but not JVM) bytecode too.

I think one of the main use cases of graal native will be for container's with smaller memory footprint (where GO traditionally shines) or where startup time needs to be fast.

This is correct. It's a proper compiler (on top of llvm) and when you use it, you can't use Java classes or libraries. Instead, Kotlin has a notion of multi platform libraries with e.g. serialization, http, and IO libraries that you use. Short term this is aimed at mobile developers looking to build libraries that compile to IOS and Android. Long term this will likely pop up in other places as well.

There's also a javascript transpiler and tools to adapt typescript definitions so you can use Kotlin for react work or node.js work as well.

It's alpha/beta there is a lot of talk about concurrency and memory management.

But yes this goes down to llvm. You can also import and compile c/c++ libraries via headers. I've been doing it recently.

This is the strength with multi platform declarations. you can write a back-end service then pick the best run time for that component.

https://kotlinlang.org/docs/reference/native/c_interop.html

GraalVM can build native images: https://www.graalvm.org/docs/reference-manual/native-image/

I haven't heard of kotlin-native, but apparently it isn't using GraalVM under the sheets which is interesting.

Kotlin Native predates the release of native-image. Also it's actually a slightly different language. Kotlin/Native really wants you to not write shared memory multi-threading. All variables are thread local by default. It has special constructs for interop with C libraries, and uses a sort of reference counting Python-esque memory manager if I recall correctly. You can only use C or other Kotlin/Native libraries.

GraalVM native images are a different matter. It uses the Java memory model and ahead of time compiles all the code to native. The "VM" part is bundled with the binary but it's very small and thin. Really it's just a simple generational GC and a bit of support for reflection over things you said you want to reflect over.

Both produce small binaries that start as fast as C programs do. In fact the GraalVM team have advertised cases where native-image binaries start faster than C programs do.

Is this like Graal (e.g. build the VM into the “native” image) or actually compiling to a just a native binary?

Yes and no. It's "like Graal" in that there is a Kotlin/Native runtime which is built into the binary. It's "not like Graal" in that it is not building in the entire JVM, and K/N code provides things like manual memory management APIs which are not available in e.g. a Java->Graal context.

GraalVM has a native-image compiler.

https://www.graalvm.org/