4 ms·

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 wh

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.

silisili 3y ago
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.
- fabian2k 3y ago
  .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.
  - unusualmonkey 3y ago
    I wouldn't be surprised if reflection usage starts diminishing, with source generators solving a number of use-cases while maintaining AOT.
    - fabian2k 3y ago
      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.
      - ziml77 3y ago
        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.
    - slaymaker1907 3y ago
      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.
      - eddythompson80 3y ago
        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.
    - pjc50 3y ago
      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).
- rbehrends 3y ago
  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-as-container?pivots=dotnet-7-0 https://learn.microsoft.com/en-us/dotnet/core/docker/publish...
- pjmlp 3y ago
  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.
  - eddythompson80 3y ago
    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.
    - pjmlp 3y ago
      Sure, as mentioned its key cases was fast startup for desktop applications. The installation was supposed to take care of calling into ngen.
    - marwis 3y ago
      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.
      - pjmlp 3y ago
        It is still there for those of us that have to deal with .NET Framework.
- SideburnsOfDoom 3y ago
  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 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#packages https://learn.microsoft.com/en-us/dotnet/core/install/linux#...
- kcb 3y ago
  dotnet is available in the big distros package managers.

silisili 3y ago

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.

fabian2k 3y ago
.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.
- unusualmonkey 3y ago
  I wouldn't be surprised if reflection usage starts diminishing, with source generators solving a number of use-cases while maintaining AOT.
  - fabian2k 3y ago
    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.
    - ziml77 3y ago
      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.
  - slaymaker1907 3y ago
    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.
    - eddythompson80 3y ago
      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.
  - pjc50 3y ago
    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).
rbehrends 3y ago
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-as-container?pivots=dotnet-7-0 https://learn.microsoft.com/en-us/dotnet/core/docker/publish...
pjmlp 3y ago
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.
- eddythompson80 3y ago
  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.
  - pjmlp 3y ago
    Sure, as mentioned its key cases was fast startup for desktop applications. The installation was supposed to take care of calling into ngen.
  - marwis 3y ago
    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.
    - pjmlp 3y ago
      It is still there for those of us that have to deal with .NET Framework.
SideburnsOfDoom 3y ago
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 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#packages https://learn.microsoft.com/en-us/dotnet/core/install/linux#...
kcb 3y ago
dotnet is available in the big distros package managers.