.NET is starting to look nice on Linux and macOS. I'm very disappointed that AOT compilation has apparently fallen on the wayside, though.
CoreRT was supposed to bring full AOT to C#, and that project is still in alpha with a disclaimer saying there are no plans to make it production-ready. LLILC, the compiler that targets LLVM, is also not production ready.
Officially it's been pushed back. The priority has been the unification of all the different runtimes and platforms first, which is coming with the big .NET 5 release.
Is there a document describing this plan? Will this replace .NET Core, CoreRT, etc.?
As someone who isn't a .NET developer, the sheer proliferation of runtimes and platforms is super confusing, and I can never remember what's what between, .NET, .NET Native, .NET Framework, .NET Core, Mono, CoreRT, etc. If this is getting cleaned up, that's great news.
.NET windows/desktop framework stopped at version 4.8 and .NET Core has spent 4 years incrementing to version 3, so .NET 5 is a merger of everything into a single framework again. Mono will still exist since it's used by Xamarin for mobile and Unity for games.
AOT is mentioned in the article and comments, and there's also this big thread in the CoreRT repo if you want to see more discussions: https://github.com/dotnet/corert/issues/7200
It's technically a merger. It's the next version of .NET Core after v3.0 but jumping ahead to v5.0 and dropping the "Core" designation, and then merging in parts of Mono, AOT toolchain, and even more of the (upgrade) bits of the classic framework.
You might be able to get pretty far with just a framework switch. The RC is already out so try it. You'll probably have to update the csproj/sln files at a minimum and fix some known API differences but it's unlikely you need an entire rewrite.
Runtimes -> This runs the IL code, includes Mono, CLR, and CoreCLR. Mono was written by Miguel Icaza to support cross platform mobile development. CoreCLR is a new version of the CLR that supports .NET core code.
Libaries/Frameworks -> .NET core, .NET framework. Two different versions of the libraries, .NET Core is newer and cross platform but older technologies such as webforms can't run on it, .NET framework supports older technologies but isn't cross platform. Plenty of libraries are usable inside either framework.
Ahead of Time Compilation Technologies -> .Net Native, CoreRT, AOT
Most new devs don't have to know any of this to be productive. Just pick .NET core unless you need to use .NET Framework for backwards compatibility reasons.
As far as .NET goes, MS has a long history of confusing messaging. As soon as something gets traction it either gets obsoleted or renamed. They would do themselves a big favor if they made it easier for people to understand the different versions.
Not only .NET, I am really pissed how C++/CX got replaced with C++/WinRT, without any effort to provide tooling with similar capabilities.
So instead of a C++ with C# like tooling for doing UWP stuff, now one gets to edit IDL files without any kind of support (you could be using Notepad for what they care), and then you have to manually copy/merge C++ files after being generated.
And on the .NET side .NET Native was looking to be how version 1.0 should have been all along, and now has an uncertain future.
Finally with Reunion, when going regularly on their issues, it seems to be turning into a major reboot, porting what they can into Windows 7 like stack, leave UWP as an improved COM runtime, and pretend that everything else post Windows 8 outside Win32 never happened.
And in this case "pushed to .NET 6" doesn't mean "not working" or anything, just not production-ready. The AOT implementation in Mono is robust and is being adapted for .NET Core, which requires changes and improvements. Not to mention the introduction of new platforms - supporting targets like Apple Silicon and WASM takes additional work.
CoreRT was supposed to bring full AOT to C#, and that project is still in alpha with a disclaimer saying there are no plans to make it production-ready. LLILC, the compiler that targets LLVM, is also not production ready.
Anyone know what's going on?