But underneath the covers, there is an extremely powerful compiler (Roslyn) and build-system (msbuild). Combine that with the flexibility of C# and you can develop pretty much anything.
Also you can now mix Win32 with WinUI via the concept of XAML island. It’s not perfect but you don’t have to be blocked in one world or the other.
Though I personally prefer dealing with WPF via AvaloniaUI, styling with winUI is often too frustrating…
However .NET (alongside Java), has a culture of great tooling, we only do stones and sticks programming when there is no way around it.
Trimming can cause bugs when your program or one of its libraries relies on reflection and Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications.
Fair enough; perhaps it'd be worthwhile to throw a compiler error if both reflection and trimming were attempted.
> Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications
This is intriguing; could you elaborate on the latter? Would tiered JIT perhaps have more runtime information which would be more useful when optimising frequently-accessed code paths or tight loops?
For most practical purposes, the default .NET 8 AOT is great if you really need native code.
The biggest issue has been WinDev, that contrary to Google's culture in ChromeOS and Android, they will kill any attempt to touch their precious COM and C++ tools, thus the way the Longhorn project went down, only to see its ideas redone in COM, and WinRT coming to existence.
Even "we care about binary size at all" would be a major step forward for most "professional" applications.
We needed it to be that small because he pager didn't have very much storage. Neomar microbrowser, we called it. We were quite pleased to get this thing so tiny, with basically compiler flags and a few recoding steps.
https://migeel.sk/blog/2024/01/02/building-a-self-contained-...
