All min kod som jag skriver i .Net kan jag köra lite vart jag vill. På en raspberry, windows server eller något annat. ARM eller X86.
Riktigt så enkelt är det tyvärr inte. "Vanliga" .Net är fortfarande bundet till Windows/x86, men antar att du refererar till dotnet core här.
Dotnet core för Windows stödjer inte Aarch64, utan man stödjer endast 32-bitars ARM och det endast för en extremt nedskalad version av Windows server.
Under Linux stödjer dotnet core 3.1 x86, x64, ARM och Aarch64. OK stöd, men långt ifrån att "köra på vad som helst" då man saknar stöd för MIPS, PowerPC etc.
Testade dotnet core på ett av mina Aarch64 Linux system genom att testa flera av benchmark game fallen. Fungerade sådär... Prestanda var ingen höjdare och just då .Net är så extremt associerat med x86/Windows var det flera exempel som fallerade då de förutsatte saker som bara är sant på x86. Det är långt mer ett .Net problem än ett Aarch64 problem då motsvarande problem inte alls finns om man kör Java, Rust eller C++.
Microsoft har även mer grundläggande problem med Aarch64 stödet. Det är ungefär ett halvår sedan Surface Pro X lanserades, ändå saknas fortfarande ett native MS Office (det trots att man redan har 32-bitars ARM stöd för MS Office), Windows 10 Pro saknar stöd Hyper V stöd på Aarch64 (men det är på gång, så om något år kanske det Windows har helt OK Aarch64 stöd).
WLS2 saknas just nu både för Aarch64 och x64, så det är ju inte ARM problem. Med HyperV och/eller WSL2 stöd kan faktiskt Surface Pro X bli någorlunda användbar, detta då man med dessa får ett vettig Linux stöd där native Aarch64 stödet är lysande!
x86 kommer leva väldigt länge, det just för att Windows (och även .Net) är så extremt bundet till x86. Möjligen blir just detta Windows fall, i "molnet" är Windows redan nu irrelevant. Windows är fortfarande totalt dominant som desktop OS och spel OS, det lär nog inte ändras i närtid... MacOS är dock i en långt bättre position att hantera en annan CPU-arkitektur, Linux är sedan länge redan där.
Många gånger har det talats om detta steg, Intel försökte själva med IA64, hittills har det inte varit ekonomiskt hållbart. Är det denna gång det första gången lyckas?
IA64 fallerade inte p.g.a. av ekonomi, det fallerade av samma orsak som majoriteten av alla försökt till "utveckling" faller på: det visade sig vara en design som hade vissa fördelar, men på det stora hela övervägde nackdelarna.
Intel gjorde egentligen allt rätt med IA64. Man insåg redan på 1990-talet att x86 passerat sitt bäst-före-datum. Intel kikade på vad spjutspetsforskningen ansåg vara vägen framåt för CPU-design, vid den tidpunkt IA64 designades var detta VLIW/EPIC.
VLIW var bra på vissa saker, IA64 fungerade faktiskt riktigt bra för de flesta flyttalsintensiva applikationer. Tyvärr visade sig VLIW vara en riktigt usel idé för generella heltalsberäkningar, det är 90+% av alla program vi kör på skrivbordet. IA64 var en dålig design som generell CPU, så designen dog p.g.a. tekniska orsaker inte ekonomiska.
AMD hade ju framgångar med VLIW en tid, deras VLIW-baserade GPUer var mer effektiva jämfört samtida Nvidia. Men när trenden gick mot allt mer generella beräkningar havererade VLIW-tekniken även där.
Aarch64 och RISC-V är också resultat av att följa de senaste forskningsrönen. Intel blev rejält bränd av IA64 fadäsen och många verkar hålla med dem i tron om att det enda som spelar roll är mikroarkitektur, x86 ISA är inget problem. Det var i praktiken sant under lite mer än ett decennium, men allt pekar på att den riktning forskningen nu tagit och som anmanats av Aarch64 och RISC-V faktiskt har massor med fördelar. Det specifikt generell heltalsprestanda där Apples CPUer totalt demolerar high-end x86 i prestanda per CPU-cykel, så denna gång verkar man faktiskt hittat relevant fördelar (som x86 inte kan implementera utan att bryta bakåtkompatibilitet).
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer