.NET 11 verlangt modernere CPUs und ersetzt Compiler-Async durch Runtime-Async
What's new in the .NET 11 runtime
Mit .NET 11 hebt Microsoft die Mindestanforderungen an die Hardware an: x86-64-v2 wird zur Baseline, unter Windows und Linux zielt ReadyToRun nun auf x86-64-v3. Ältere CPUs laufen nicht mehr. Zudem führt das Release Runtime Async V2 ein, das compiler-generierte State Machines durch Laufzeitverwaltung ersetzt – mit saubereren Stacktraces, besserer Debugbarkeit und weniger Overhead. Die Runtime-Bibliotheken selbst sind bereits damit kompiliert.
Mit Runtime Async erscheinen die tatsächlichen Methoden direkt auf dem Aufrufstapel.
- CharlieDigital
Meiner Erfahrung nach werden C# und .NET beide zu einem großen Teil aufgrund des Erbes „unterschätzt“. Manche Leute da draußen denken immer noch, .NET sei nur für Windows. Manche haben sich C# seit den .NET-Framework-Tagen nicht mehr angesehen. Manche sind immer noch verbittert über einige von Microsofts Entscheidungen rund um OSS (Debugger, Hot-Reload-Fiasko usw.).
Aber tagtäglich mit C# und .NET für Backends zu arbeiten? Das ist wirklich fantastisch. KI scheint es sehr zu mögen, und viele Tools für Agenten, um richtig loszulegen. Roslyn-Analyzer, Source-Generatoren, brauchbares Hot Reload (für eine kompilierte Sprache), jede Menge wirklich guter Dokumentation von Microsoft, im Allgemeinen geringe Varianz und hohe Konsistenz von Codebasis zu Codebasis (z. B. im Vergleich zu Drizzle vs. Prisma vs. TypeORM vs. Kysely vs. ... im Node-Land).
Mein vorheriges Team wechselte von TS zu C# und F#[0][1], und es war ein Segen; viele der Plattform-Ops wurden vereinfacht. Es ist einfach eine sehr solide Toolchain, und die Pakete sind im Allgemeinen stabil (viel weniger Aufwand für die Pflege von Plattformkonfiguration/Tooling und mehr Fokus aufs reine Bauen). Erstparteien-Pakete erhalten konsistente Sicherheitsupdates, und C# hat nicht annähernd die gleiche Exposition gegenüber transitiven Paketen, die man im JS/TS-Ökosystem antrifft.
C# fühlt sich im Zeitalter des KI-Codierens wegen seiner allgemeinen Stabilität, des starken statischen Analysators, der Beharrung auf Typen und des wirklich guten Toolings als eine sehr solide Wahl an. Nicht für alle Anwendungsfälle richtig (z. B. CLI, serverlose Funktionen), aber fantastisch für Backend-APIs.
Wenn du dir gerade überlegst […]
- giancarlostoro
C# war meine zweite Programmiersprache nach VB6. Ich erinnere mich an die frühen 2000er, als ich 12 war und den Computer meines besten Freundes benutzte, um zu versuchen, VB .NET herunterzuladen (er hatte schnelleres Internet), nur weil es kostenlos war, und dann extrem enttäuscht war, als ich meine VB6-Projekte, die ich darauf ausführen wollte, nicht einfach laufen lassen konnte ... Einige Jahre später, so um 2007 bis 2009, probierte ich C# aus, und das war lebensverändernd.
Ich ging schließlich nach der Arbeit im Einzelhandel bei Disney aufs College, und nach dem College sollte mein erster Job C# sein, aber sie hatten das Projekt nicht genehmigt, also bekam ich meine erste Berührung mit Python – das ich liebte –, dann JavaScript – das ich hasste, aber bis heute eine Hassliebe pflege – und schließlich C#, aber es war nicht .NET 3.5, nein, sie begannen .NET Core zu verwenden, was ... etwas anderes war, viel Zähneziehen in den frühen .NET-Core-Tagen.
So viele wunderbare Projekte, die mit .NET gemacht wurden; mein einziger Kritikpunkt ist, dass ich mir wünschte, Microsoft würde einen plattformübergreifenden GUI-Stack machen, an dem sie tatsächlich festhalten, und ihn auch unter Linux zum Laufen bringen. ;)
Ich weiß, es gibt Alternativen, aber nichts schlägt es, seinen Kollegen zu sagen: „Lasst uns einfach das Eingebaute nehmen“, wenn man einen GUI-Stack auswählt.
- wofo
Großartige Sache, wie immer bei .NET-Releases! Die Runtime-Async-Unterstützung überrascht mich ... Ich verstehe, dass Stack-Traces ohne State Machines im Code freundlicher sind, aber ich hätte nicht erwartet, dass sie auf eine Runtime-Version umstellen und gleichwertige Performance haben könnten. Cool!
- 1a527dd5
https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
Sei dir bewusst
(decimal)0.1
// .NET 10: 0.1
// .NET 11: 0.1000000000000000055511151231
- mgdev
Ich habe das Gefühl, sie haben viel getan, um die vielen verwirrenden Versions- und Runtime-Kompatibilitätsprobleme zu lösen, die Nicht-Windows-Entwickler davon abgebracht haben, .NET zu verwenden.
Allerdings leiden sie immer noch unter einem unglaublichen Branding-Problem.
Es ist wirklich schade, denn als Runtime ist es ziemlich beeindruckend, und besonders F# macht Spaß. Sie haben auch gute plattformübergreifende Unterstützung und Tooling, was sie vor einigen Jahren nicht hatten.
Kombiniere das mit der Tatsache, dass sowieso niemand mehr wirklich Code schreibt dank KI, und das könnte ein Volltreffer als Runtime für eine KI-native Entwicklungsumgebung sein.
Aber es wird nie passieren.
- GaProgMan
> .NET 11 ist ein Standard Term Support (STS)-Release mit zwei Jahren Support gemäß der .NET-Supportrichtlinie. STS- und Long Term Support (LTS)-Releases haben die gleichen Qualitäts- und Servicing-Richtlinien; der Unterschied ist die Länge des Supports. .NET 10 bleibt eine unterstützte LTS-Option. Bleiben Sie mit Servicing-Updates auf dem Laufenden, egal für welches Release Sie sich entscheiden.
Sie haben die Hauptaussage hier vergraben.
- .NET 10 wird am 14. November 2028 das Ende der Lebensdauer erreichen
- .NET 11 wird am 9. November 2028 das Ende der Lebensdauer erreichen
Das bedeutet, dass jeder, der auf 11 aktualisiert, weniger Support-Tage hat. Aber die Idee ist, dass man auf 12 aktualisiert, sobald es RTM ist.
Das Problem dabei ist, dass ich Kunden habe, die sich weigern, von 2.1 abzurücken (oder auch nur auf das 2.1-Re-Release 2.3 zu aktualisieren).
- jotato
Welche IDE benutzen die Leute heutzutage für C#? Damals (um 2008) war Visual Studio die einzige wirkliche Option.
Aber ich bin jetzt auf Linux. Wenn ich wieder einsteigen wollte, was sollte ich dann verwenden?
- SurajMishra
Für die Funktionen, die sich zwischen Go und .NET überschneiden, kann mir bitte jemand sagen, warum Leute .NET statt Go für Nicht-Legacy-Systeme wählen? Nach meinem begrenzten Wissen ist Go in Syntax und Speicher viel effizienter.