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…
Hence why there is even documentation on how to migrate, now legacy.
https://blogs.windows.com/windowsdeveloper/2014/07/24/introd...
"Roadmap for Windows Runtime apps using C++"
https://learn.microsoft.com/en-us/previous-versions/windows/...
"Win32 and COM APIs for UWP apps"
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-an...
Specially the subsection "Alternatives to Win32 and COM API".
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?
The tooling already generates warnings for any spot in the program that uses reflection _in a way that cannot be statically analyzed_. Fixing code to make it work with trimming is equivalent to fixing warnings. Here are a couple case studies: https://devblogs.microsoft.com/dotnet/creating-aot-compatibl...
Exactly. In addition to that, it's hard for the compiler to guess which branch is the frequent one in code. Or if it's the only one, if, for example, you link against implementations of some interface but only use one at runtime.
In language/platform with dynamic loading, it's hard for the compiler to "perfectly" predict which piece of code will ending up being executed at compile time. I think would result in a lot of false positives.
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.
From the forced rewrites across Windows 8, 8.1 and 10, as the platform was maturing, the deprecation of C++/CX, replaced by less capable C++/WinRT (now in maintainance, while they are having fun in Rust/WinRT), deprecation of .NET Native without parity in Native AOT, no designer, and plenty of other broken stuff.
It was for this that WinDev kind of sabotaged Longhorn efforts, thanks very much.
Meanwhile Google shows what happens when everyone pushes into the same direction, even if it takes some growing pains (with lots of cash) to get there.
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-...
