3 ms·

AOT is not a panacea and comes with some restrictions/trade-offs that need understood before depending on it in production.

• ziml77 6mo ago
  Losing dynamic PGO by using AOT compilation could be a detriment to performance in long-running applications, right?
• Rohansi 6mo ago
  You also have the option to do single file deployment where it self-extracts the runtime when you run it. It's not as nice but it works and maintains full compatibility.
  • hnrodey 6mo ago
    While that is nice it’s not AOT, is it?
    • Rohansi 6mo ago
      Yes, but it's still a single-file deployment option that can easily cross-compile. Just with slower startups.
• peter_griffin 6mo ago
  wouldn't you have the same restrictions/tradeoffs using go (or other compiled languages)? I've never used go, am curious
  • Rohansi 6mo ago
    Pretty much, yes. For example reflection is severely limited in .NET AOT vs. JIT, runtime generated code is more common than you'd think and cannot be done AOT. Go was designed for AOT so they already built everything around the limitations because it never supported more. It'll just take time for .NET to catch up where the dependencies you need automatically work with AOT builds.