Hacker News Reader

Comment by fabian2k | Hacker News Reader

.NET uses a lot of reflection, and you need to replace that with other mechanisms for AOT.

And for modern .NET (previously named .NET Core, the version that also runs on Linux) you can package the runtime with the binary. You can even create single-file executables there, though those are still not AOT.

The main advantage of AOT is startup time, and that didn't use to matter much for the kind of applications .NET was used for. It matters more now with serverless stuff like AWS Lambda.

View on HN

I wouldn't be surprised if reflection usage starts diminishing, with source generators solving a number of use-cases while maintaining AOT.

I doubt it will reduce all that much. It’s still really convenient and it’s way more difficult to write and use a source generator than it is to just use reflection. Source generators will get used for stuff that really benefits from the extra safety and from the increased performance, but that still leaves many use cases for reflection.

I see most foundational libraries doing the effort to move to source generators everywhere possible. It's a big multiplier. Then it's up to the applications authors to choose if they care or not about AOT.

I think that is likely, though the current source generators are often a bit cumbersome to use. Though that is why they're adding interceptors, which while it is a bit of a controversial feature is kinda necessary to implement source generators without having an annoying API.

I looked into making a source generator over using reflection and quickly gave up on it. I swear it's easier to directly generate function implementations at runtime by emitting IL than to process the syntax tree.

I'm about to embark on writing a source generator for XML serdes, because while the system XML one does support source gen, and always has, it has some annoying limitations (same element name must always map to the same class within the same assembly).

Reply on news.ycombinator.com