[hnrodey]

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

[Rohansi]

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]

While that is nice it’s not AOT, is it?

[Rohansi]

Yes, but it's still a single-file deployment option that can easily cross-compile. Just with slower startups.

[ziml77]

Losing dynamic PGO by using AOT compilation could be a detriment to performance in long-running applications, right?

[peter_griffin]

wouldn't you have the same restrictions/tradeoffs using go (or other compiled languages)?

I've never used go, am curious

[Rohansi]

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.