.NET has come to be a very solid, performant, cross-platform, productive runtime. I always come back to it for most projects. Thanks to everyone involved!
Why shudder? Sure, devops to VMs instead of .NET Core containers isn't as nifty but there is something to be said for code that can run for 5+ years without needing to be touched. Zero-maintenance is a big selling point but right now MSFT is requiring us to update ALL of our code just to rev the version every 36 months (not counting security issues -- we lost more than two weeks of productivity eradicating the Newtonsoft exploit at my last company).
Staying with .NET Framework is a factor that increases talent attrition and the cost because less people are willing to work with it. This is without discussing technical downsides.
You're assuming a workshop where there's just one significant app. The last several places I've worked there were dozens of apps, microservices, and APIs; some of the old and stable APIs were .NET Framework and those never needed to be touched. We built all of the new hotness using .NET Core, Blazor, and whatever the JS framework de jour was, all without needing to touch the old, stable, and working Framework code happly humming along in its VM.
> Staying with .NET Framework is a factor that increases talent attrition
100% this. If a company is not willing to move the product forwards because "there is no need to" then I would be looking else where. .NET Core will be a decade old very soon and a company not willing to move to that tech stack is just pure neglect.
Better later than never, I was disappointed with NGEN capabilities, given the Delphi influences on .NET.
Microsoft research had Sing#, System C#, which never came to us, Mono AOT had its issues, and finally Windows 8.x MDIL/Bartok, UWP .NET Native, which were still special cases.
I always vouched the opinion that had .NET supported AOT properly since the beggining, there would have been much less people reaching out to C and C++, as one of the reasons was getting real executables (same applies to Java, and the issue AOT until recently being a commercial JDK feature for deep pockets).
Last time I tried I had troubles. My understanding is open generics (like List<T>, without specifying T) don’t fully compile because Native AOT lacks a JIT to handle unspecified types at runtime. Closed generics work fine, though, as they’re fully known at compile time. Am I wrong in my thinking?