alt Hacker NewsMicrosoft's biggest mistake was .Net being a Java competitor when it should have just been like golang producing native binaries. Especially since .Net was realistically only going to succeed on x86/64 at that point (late 90s and 2000s). This shut the door on C# for consumer UIs, and people stuck to Visual Basic and MFC.
It took them more than 2 decades to finally support pure native binaries (via NativeAOT). And it's fantastic for servers on Linux.
Replies
They were recovering from all of the security fiascos of software that wasn’t being updated. So they pushed as much as they could into the core libraries and forced only one version to be installed at a time- so they could easily push security fixes.
This led to one of the trickiest things for early .NET consumer apps- getting the latest runtime installed.
The problem was in the early 2000s it was basically accepted x86 was a dead end whose days were numbered.
Itanium was the heir apparent but importantly basically vaporware. How do you develop software NOW and more importantly sell and ship software NOW that'll work on a CPU you don't have access to and for which good compilers don't really exist yet? I remind you in the days where online updates were a luxury at best.
Processor agnostic CIL/JIT code was the prescribed solution at the time. Java had lit the way, and it was the only "clear" path forward for better or worse.
Little did we know Itanium would implode, and x86-64 would rise and give 20+ more years of binary compatibility.