Hacker News Reader

Comment by fabian2k | Hacker News Reader

This is for native AOT binaries, not for the typical case. Though this release and the previous ones did contain improvements for trimming binaries, which is what you need to use to make non-AOT binaries smaller.

View on HN

Curious - why isn't it the typical case? .NET runtimes on Linux itself are rare enough, I figured AOT on Linux would be about the only use case, especially in containerized environments.

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

I wouldn't be surprised if reflection usage starts diminishing, with source generators solving a number of use-cases while maintaining 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 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'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).

You can also publish .NET apps/services directly as container images [1].

Or you can distribute them as a single file, standalone, "ready to run" application, which precompiles your methods and includes the JIT. This results in a larger executable, but keeps all the functionality, including reflection and runtime code generation, intact.

And, of course, you can install .NET core directly on your Linux system, just as you would for Python or Ruby (where you also don't usually rely on the default installation).

[1] https://learn.microsoft.com/en-us/dotnet/core/docker/publish...

Actually many people seem unaware that .NET has supported AOT since the beginning.

The reason that they are unaware, mostly is that using NGEN requires really wanting to use it, as it requires dealing with strong named Assemblies, aka signed .NET libraries/executables.

It only supports dynamic linking, and still pings back on the JIT for more complex code sequences, its original goal being fast startup time for desktop applications.

Thus before .NET Native (UWP only), Mono (iOS/Android), and now Native AOT, doing AOT compilation on .NET was largely ignored, despite NGEN being available.

ngen had a lot of problems though. It was very easy to accidentally invalidate it. There was no easy reliable way to "ship" an ngen output. There was no easy way to even check if its even loading. your best option was to run ngen on the target machine, which is fine for services as a deployment step. But it's not like you could build and publish an AOT .NET cli for example.

Sure, as mentioned its key cases was fast startup for desktop applications.

The installation was supposed to take care of calling into ngen.

I think not shipping ngen output was desired. There was an NGen Optimization Service that would reoptimize code when net framework was updated and possibly with new profiling data.

It is still there for those of us that have to deal with .NET Framework.

What does it mean that ".NET runtimes on Linux are rare" ?

They exist, they're easy to install (1), but more importantly for containerized environments, you can start with a standard image e.g. https://hub.docker.com/_/microsoft-dotnet-aspnet

Having the .NET runtime on the target machine isn't one of the pain points in a production deploy.

As others have pointed out, having AOT compilation, with its faster start-up time, along with smaller binaries is aimed at a different perceived pain point: the cold-start performance of lightweight function apps / AWS lambda.

1) https://learn.microsoft.com/en-us/dotnet/core/install/linux#...

dotnet is available in the big distros package managers.

Reply on news.ycombinator.com