Hacker News Reader

Comment by dotschnet | Hacker News Reader

That’s a dishonest question, take any code base >10000 slices, it will not work with aot ootb.

Read the docs of what’s missing, if you are honestly interested in what’s missing.

https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

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

View on HN

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).

That heavily depends on the use case. Game developers that use C# adopt NativeAOT with zero friction, it's just a natural fit

  Reflection, is one thing.

It's a common misconception, somehow. Reflection works in AOT.

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.

[1] https://learn.microsoft.com/en-us/dotnet/api/system.runtime....

This attribute makes the compiler generate IL code as if the target member was accessible to the user code. It's orthogonal to AoT and reflection.

This works perfectly fine with AoT:

  var writeLine = typeof(Console).GetMethod("WriteLine", [typeof(string)]);
  writeLine.Invoke(null, ["Hello world"]);

As you can see, there are no UnsafeAccessorAttribute's. Plain old reflection that just works (why should it not?)

https://godbolt.org/z/Yv8hadYqv

> 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.

Reply on news.ycombinator.com