What you are looking for is called F#. You get native interop with C# and access to all .NET/C# libraries as a bonus. We use it as a daily driver for a complex B2B2C cloud platform.

Does it not run in a VM?

Yes you are right, it does not properly support NativeAOT yet.

But it isn't a need for most use cases, unless you want to do mobile development and meet app store policies. But even then, mature F# frameworks like Fable transpile your F# code to React & Cie.

It can be compiled, but that’s not the use case it was originally designed around, so it’s not quite as first class an experience as with Go or Rust.

You can embed the framework into the application so it is a single distributable.

C# doesn't depend on a VM these days when it is AOT compiled. Same for Java, though C# is rather more user friendly in how it goes about it.

> C# doesn't depend on a VM these days when it is AOT compiled

Maybe I’m being pedantic, but this is an oxymoron. Also the premise is incorrect. It’s not like the VM is gone. Merely baked into the code at compile time. It compiles IL to native code. Same for IL2CPP. The VM is still there.

The term “virtual machine” is confusing. I think you meant to say JIT compiler :-)

The trouble with that level of pedantry is that you then can point to LLVM as a VM and say that Clang and other C/C++/Rust tools that AOT through LLVM are "too tied to a virtual machine". Then you can go back through the history of cross-platform optimizing C/C++ compilers and find VMs in the design in almost all of those, too. LLVM is not hiding it in its very clear name, but low-level VMs were a thing for decades before someone named LLVM.

VMs have a long history in cross-compilation, even for "low-level" languages like C/C++. The AOT versus JIT distinction is blurry, and the "VM language" versus "non-VM language" boundary is blurrier still, especially when you take into account "standard runtimes" such as glibc and vcrt and whether or not those are statically linked.

Is a C program with a compiled with Clang through the LLVM dynamically linking a glibc and statically linking a Boehm GC library "running in a VM"? There's no wrong answer, it's a lot shades of gray. I believe almost every pedantic way to answer that has an equally pedantic counter-argument.

There are plenty of languages in that niche you could be using. OCaml, Haskell, F#...

Kotlin has a LLVM backend, among others.

Roc might be that language one day. Not yet because it's pre-0.1.

C#, with default tooling, can compile without needing a VM, for windows, macOS, linux and some other platforms.

I wish that Nuget would show which packages are NativeAOT compatible.

It will probably get there one day since all BCL is annotated. Perhaps this is not done because you can have parts of the library be completely safe to use in AOT while another part not be.

That's the problem though. People want one language to be The One (tm) and that's just not possible. Your The One (tm) isn't mine.

I don't see why a VM is a problem, personally, and I like a lot of what C# has been exploring with `Span<T>` and `Memory<T>` for safe low-level memory management in a garbage-collected language. Some of it seems like a simpler Rust. Rust can still do plenty of memory lifetime things that C# can't, but the gap is smaller than ever and C# is still slowly growing its capabilities in that space. All that in a language where you don't have to start with the low level tools, you can prototype entirely in higher-level garbage collected space and use real world performance to guide optimizations towards the low-level memory management tools only when they become truly necessary.