Hacker News new | ask | show | jobs
by ComputerGuru 2214 days ago
It’s a really good crash course on the shared origins of Delphi and C# plus a brief reminder of all the modern features offered by Delphi that have flown under the radar, but the anger and emotion is rather immature and really detracts from the argument. Those words could have been better spent selling its strengths further.

That aside, things have changed rapidly in the last five years in the C#/.NET world first with .NET Native then with .NET Core and CoreRT. Exciting times, really.

2 comments

Unfortunately .NET Native seems to be on the way out with the project Project Reunion, and it is not clear how AOT support will be like post NET 5 release.

So far they are demoing single file release, which is basically packing everything into the same exe, but you get a JIT + MSIL instead.

I agree. .NET Native was always for the full framework only; I think CoreRT was supposed to be the future there but it seems to be put by the wayside now as with .NET Core 3 the official recommendation for AOT was Mono with no mention of CoreRT in the roadmap. I would love to hear from Miguel what the plans are there.

Ironically this comes at the same time that C# the language has become much more usable without GC or with minimal GC thanks to the work that went into implementing Span but I think that was more a matter of necessity to support advanced async features for web usage (although I found it also made P/Invoke a joy and eliminated virtually all my need for marshaling in a few codebases.. and would have eliminated all the performance issues the led the OS team to abandon C#). It does seem that the ASP/Blazor team is driving the show and calling the shots after the UWP failure in terms of adoption, and I’m not seeing too much that would indicate it’s not the case even with Project Reunion. I’ve been testing WinUI 3, MSIX, and WebView2 and have been disappointed at the lack of story for putting all the parts together. It seems like side-loading packages with sparse package projects is intended to replace “native” UWP packages (“regular” AppX packages require .NET native unless side-loaded and I can’t get apps pulling in WinUI/STJ/Buffers/etc code to compile to .NET Native without an undeclared dependency on System.Private.CoreLib and without serious hacks to enable RTTI which makes me think they’re not meant to be used in that way any longer) but as always MS isn’t very forthcoming about the future of UWP components more than a single step at a time with all bets clearly hedged.

In C# 9 there will be Source Generators, an easy way to generate code in a build task before compilation. That will remove the need for Reflection in many areas. Work is also underway to identify and remove all "linker" dangerous code. Once the SDK is linker safe and has a lot less reflection, AOT becomes a lot easier.

Mono is now part of the dotnet family so I suspect they are going to use that for AOT in C# forwards. Starting with Blazor.

The low level stuff seems to have come from three fronts, high performance Web servers (trying to be on top results at TechEmpower), improving overall performance for Unity/MonoGame/Xenko, and given their position regarding safer languages, reducing the need to jump into C++/CLI for performance.

Project Reunion seems to be the start of long roadmap to bring UWP tech into Win32, as if Windows 8 had introduced UWP as Win32 evolution without the additional application model.

So if developers don't migrate en masse into UWP, bring UWP APIs (COM v2) to all Windows developers and in 10 years from now pretend that Windows 8.x (UAP)/W10 UWP never happened.

I used to believe in UWP despite all its issues, still think C++/CX was the closest that Microsoft ever came to having their own C++ Builder (C++/WinRT tooling is still too clunky), and .NET Native was what .NET should have been since day one.

Oh, well lets see how all of this will turn out.

IL2CPP won't come to .NET Core world?
IL2CPP is Unity product and designed to work together with their new B̶l̶a̶z̶o̶r̶ Burst compiler toolchain.

It is quite different than a general purpose AOT compiler for .NET, as it also takes into account HPC# code patterns.

I'm not 100% on this, but I'm pretty sure that HPC# has a separate, LLVM-based compiler.
Unless something has changed, Burst also uses IL2CPP.

https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual...

As far as I can see, if it's AOT compiled it requires the same linker tooling as IL2CPP does, but is otherwise separate from it.

https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual...

sometimes channeling a bit of anger as an engineer can be a pretty good motivator to do things The Right Way(TM). that is to say, I have some sympathy with engineers being angry at technology - obviously it's not ideal as a communication tool like here...