Overall, I think the big win for Rust is when you need low-level, low-cost, low-memory, high-performance applications, at the cost of anything else. Rust is a great replacement for low-level C.

Unfortunately, those are not the features that you care about most in a compiler. In a compiler, your priorities are ease of extension, ease of specification, and ease of transformation. The last thing you want in a compiler language is to worry about ownership when trying to implement expression-rewriting optimizations. Conversely, OCaml is excellent at these things.

Its use can be justified elsewhere, but it should always be understood that manual memory management is always going to be more difficult.

The problem I see, and the reason I sometimes reach for rust when I don't really require manual memory management, is that nothing else is really better for strongly-typed statically-compiled self-contained executables.

Go: it's got the convenience and packaging and ecosystem, but an absolute shit type system.

F#: carries around the baggage of the CLR, and the best tooling is Windows-exclusive. Type system is good but not as good as others.

Scala: absolutely amazing type system, but lots of unneeded stuff too. JVM packaging is a huge pain, and pretty heavy weight. Native compilation options are few and have slow executables in comparison.

OCaml: tiny ecosystem, multicore is always one year away, some weird ergonomic choices.

Haskell: lazy, IO has terrible ergonomics, and the community consists of pie-in-the-sky type theorists.

I would kill for a Dotty-like (Scala 3) native programming language that could omit all of the bullshit that was required to fit into the JVM and work with java libraries.

The state of natively compiled GC'd languages is actually pretty bad, at least ones with an ecosystem/job opportunities.

You either have to run into the same problem as dark when it comes to libraries and ecosystem (ocaml, haskell, D, etc), use go and give up any nice language features, or run on a VM and deal with all the issues of packaging/weight (clr, jvm).

When packaged alongside the binary, VM for all purposes is just the language runtime,e.g. natively compiled Java.

I just don't think natively compiled Java is there yet. It's not trivial to get it working and the ecosystem isn't ready for it yet.

There are certain things that just work (i.e. quarkus, which I have a web service running on 13 mb of ram), but I have never been able to successfully compile to native on my own because of library dependencies. Getting things like Weld or H2 to work is pretty difficult.

It is there since 2000.

AOT compilation has been a feature of most commercial JDKs, specially the ones targeted at embedded development like PTC and Aicas.

jlink potentially helps with weight.

Don't forget SML. A wonderful, simple language with great compilers and multithreading, but little tooling I'd library support.

To me, it looks like the sweet spot might be RC + weak references, which in terms of ease of use is close enough to a tracing GC as to not matter, + the ability to tune away the RC ops in specific circumstances, for example using affine types.