1. That still needs a GC, and thus heap space. Unless you make everything stackalloc which is impossible in kernel programming
2. It is heavily pinned by unnecessary metadata. Well, actually some maybe necesdary to facilitate GC but it is bloated anyway
3. RyuJIT is not as optimized as LLVM, and RyuJIT produced the AOT code. There in an abandoned project called LILAC attemping to use LLVM as a second AOT generator but it was never heard from again after 2019.
4. Native interoperability in .net requires JIT as well, to generate things like call sites and runtime thunks (function pointers to restore CLR context). Not only that wastes more resources but also that not all P/Invoke calls can be AOT compiled.
1. Well technically speaking, you need a unified heap space. Just like in Linux kernel you have vmalloc and kmalloc which does virtual memory and real, page-aligned physical memory. So this is technically means I will have to pre-allocate everything. But it is not gonna work, how do you save space?
2. "necessary". I should have enabled autocorrect on my phone, it does more good than harm this time if I had it on.
3. It's actually LLILC (https://github.com/dotnet/llilc). I just remembered how to pronounce it. But if the name is wrong, then you have to correct it.
That list just shows people have been experimenting with such things for decades, including in a major push with Midori: over 100 devs across Microsoft and Microsoft Research, and while things have been learned and fed into the development of runtimes and operating systems it hasn't changed the fact that all the major OS kernels are written in non-memory-safe languages. Rust, on the other hand, is starting to directly impact these kernels.
Joe Duffy himself said with Midori they "started with C# and .NET [but] were forced to radically depart in the name of security, reliability, and performance" and that at one point they had 11 different garbage collectors. The jury is still out (and has been deliberating for an awfully long time) on whether you can build or even contribute to a successful, mainstream, general-purpose OS kernel in a garbage-collected language but a distinctive selling point of Rust is that you can start adding memory safety without having to. And the fact that this is actually starting to happen to more than one such kernel while Rust is still a fairly new language could be interpreted as evidence that maybe, just maybe, the GC really was the problem all along.
Joe Duffy also said at his Rustconf keynot that even with Midori running in front of their eyes, many on Windows kernel developer team dismissed it as impossible.
Maybe, just maybe, the problem isn't technical, rather human, and that can only be tackled one funeral at a time.
Programming is a human activity and will remain so for the foreseeable future afaics. I've had a taste of the approach to development required to get good performance in GC'ed languages and it wouldn't surprise me if it's just incompatible with the way most system programmers think. And if that's the case it's a real problem for that approach and I doubt funerals will help it unless there's a concrete reason for later generations of the kinds of developers needed for kernel development to think differently. "You can't get memory safety without GC so they'll be forced to learn" no longer applies (if it ever did) thanks to rust.
As proven by them being draged to write Swift and Java/Kotlin code on mobile devices, or the way WASM is being pushed into CNCF projects, a little steering with more painful alternatives if they keep to their old ways, helps a lot.
By contrast newer generations don't think C and Assembly is the only way to program a mobile device, or embedded system, see MicroPyton and JavaScript in the maker community among school kids.
Which in many cases has already been proven by making it part of the kernel, even if Xerox, DEC/Olivetti, ETHZ, MSR projects weren't made available to wider audiences.
One can do a Google, and push it no matter what, or give up and take the adoption path that is easier to bring the safety luddites along for the ride.
For me, Rust is a nicer Ada like effort, a kind of compromise.
We can wait the usual progress rate of one funeral at a time until a new generation buys into fully managed OS, or another Google/Apple big spender forces them into developers no matter what, which most likely I will not live through.
So we're left with the compromise of allowing only userspace for managed languages, while adopting something like Rust for the "only over my dead body folks" anti any form of automatic memory management languages.
Given that even the success stories of bare metal deployments of managed runtimes doesn't change their minds anyway.
