Self-contained != static compilation though. The self-contained binaries still have pretty poor startup time and are large since they contain the whole JIT.
I used it recently to write a useful utility related to OpenTelemetry file processing. .NET AOT produced a single-file static binary which is similar in size to what Go would produce, and can be dropped into any target system and run without dependencies, just like Go does.
Reflection, is one thing. Of course some runtime stuff are missing, but the problem is that no one is using source generators before trying out aot, so as soon you try aot you just meet a wall of compilation errors. Most people just want to be able parse a json file without jumping through hoops. Bad DX
The JSON source generators are quite good, and a small performance boost worth considering even when not planning for AOT. The logging and RegEx source generators aren't even for AOT but for improving debugging tools [1] and performance.
Everyone should be exploring source generators already whether or not they expect to try out AOT.
[1] Debugging source generated RegExes is a dream, including being able to breakpoint inside a RegEx in the .g.cs file should you need to trying to get a tricky RegEx right. The code generated by the RegEx Source Generator is incredibly readable and includes great comments that explain what the RegEx does, step by step. Those comments show up as documentation comments on the partial .cs file side once the file is generated and can be used to double check that the RegEx you wrote matches what you expect it to do as you write/update the RegEx and the source gets regenerated (which happens pretty fast).
It works through the new UnsafeAccessorAttribute [1]. This provides the information needed for AOT to know what needs to be in the final binary and not trimmed. It also removes the lookup overhead associated with normal reflection which is very nice.
> Plain old reflection that just works (why should it not?)
I definitely don't fully understand the landscape, so I could certainly be wrong, but I assumed that normal reflection didn't work in AOT because after trimming that method may or may not be there. If it was never called in a normal way then the compiler doesn't know that `Console.WriteLine` was being used as `GetMethod` may have a runtime value as a string rather than a constant value known at compile time. If the compiler didn't know it was being called then it will be trimmed out of the final binary whereas with `UnsafeAccessorAttribute` it provides the information required to not trim it.
Edit: I tried the following https://sharplab.io/#v2:D4AQTAjAsAUCAMACEEB0AlApgMwDaYGMAXAS... and it fails when I provide the type and method for Console.WriteLine as arguments. If I was to add `typeof(Console).GetMethod(args[1], [typeof(string)])!.Invoke(null, ["dummy"]);` to it before the `Type.GetType` call it seems to be enough to not trim out the `Console` type and the `WriteLine` method. The compiler seems to at least be smart that way.
It is not so dishonest, and you explicity added the small "ootb" to your statement. That is the point, out-of-the-box it might not work and you will have to do some refactorings, but if you start a new project with AoT you will keep it in mind.