.NET 11 drops older CPUs and moves async into the runtime itself
What's new in the .NET 11 runtime
.NET 11 raises the minimum hardware baseline to x86-64-v2 and armv8.0-a plus LSE on Windows, so older chips will simply refuse to run. The bigger shift is Runtime Async V2, a preview feature that replaces compiler-generated state machines with runtime-managed suspension, cutting a 13-frame async stack trace down to 5. The runtime libraries themselves are now compiled with runtime-async enabled, and a batch of JIT improvements—bounds-check elimination, constant string folding, faster Math.BigMul—lands alongside.
The update to the minimum baseline was made to reduce the maintenance complexity of the codebase and to better align with the documented (and often enforced) hardware requirements of the underlying operating system.
- CharlieDigital
In my experience, C# and .NET are both "underappreciated" in a large part based on the legacy.
Some folks out there still think .NET is Windows only. Some folks out there haven't looked at C# since the .NET Framework days. Some folks out there are still salty about some of Microsoft's decision around OSS (debugger, hot reload fiasco, etc.)
But day to day working with C# and .NET for backends? It's really fantastic. AI seems to like it a lot and a lot of tools for agents to go HAM. Roslyn analyzer, source generators, workable hot reload (for a compiled language), tons of really good docs from Microsoft, generally low variance and high consistency from codebase to codebase (e.g. encountering Drizzle vs Prisma vs TypeORM vs Kysely vs ... in Node land).
My previous team switched from TS to C# and F#[0][1] and it was a blessing; a lot of the platform ops have been simplified. It's just one very solid tool chain and packages are generally stable (a lot less effort on maintaining platform config/tooling and more focus on just building). First party packages get consistent security updates and C# doesn't have nearly the same level of exposure to transitive packages that one encounters with JS/TS ecosystem.
C# feels like a really solid choice in the age of AI coding because of it's general stability, strong static analyzer, insistence on types, and really good tooling. Not right for all use cases (e.g. CLI, serverless functions), but fantastic for backend APIs.
If you're looki […]
- giancarlostoro
C# was my 2nd programming language after VB6. I remember in the early 2000s when I was 12, using my best friends computer to try and download VB .NET (he had faster internet) just because it was free, then being extremely disappointed when I couldnt just run my VB6 projects I wanted to run on it... Some years later, during 2007 ~ 2009 I tried out C# and that was life changing.
I wound up going to college after working retail at Disney, then after college, my first job was supposed to be C# but they didn't have the project approved, so I got my first exposure to Python - which I loved, then JavaScript - which I hated but have a love-hate with to this day, and finally C#, but it wasn't .NET 3.5 no, they started using .NET Core, which was... something else, lots of teeth pulling during the original .NET Core days.
So many wonderful projects made with .NET my only complaint is I wish Microsoft would make a cross-platform GUI stack they'd actually stick to, and make it work on Linux too. ;)
I know there's alternatives but nothing beats telling your coworkers "lets just use the built-in" when choosing a GUI stack.
- 1a527dd5
https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
Be aware
(decimal)0.1
// .NET 10: 0.1
// .NET 11: 0.1000000000000000055511151231
- wofo
Awesome stuff, as usual in .NET releases! The runtime async support is surprising to me... I get that stack traces are more friendly without state machines in the code, but I didn't expect they could switch to a runtime version and have equivalent performance. Cool!
- mgdev
I feel like they've done a lot to resolve a lot of the confusing versioning and runtime compatibility problems that drove away non-Windows developers from using .NET.
However they still suffer from an incredible branding problem.
It's really too bad because as a runtime it's fairly incredible, and F# in particular is fun to work with. They also have good cross-platform support and tooling, which they didn't have a number of years ago.
Combine that with the fact that nobody really writes code anyway thanks to AI, and this could be a slam dunk runtime for an AI-native development environment.
But it will never happen.
- GaProgMan
> .NET 11 is a Standard Term Support (STS) release with two years of support under the .NET support policy. STS and Long Term Support (LTS) releases have the same quality and servicing policies; the difference is the length of support. .NET 10 remains a supported LTS option. Stay current with servicing updates whichever release you choose.
They burried the lede on this one.
- .NET 10 is end of life'd on Nov 14th, 2028
- .NET 11 is end of life'd on Nov 9th, 2028
Which means anyone who upgrades to 11 has fewer days of support. But the idea is that you'll upgrade to 12 as soon as it's RTM'd.
The problem with that is I have clients who refuse to budge from 2.1 (or even upgrade to the 2.1 re-release: 2.3).
- jotato
What IDE are people using for C# these days? Back in the day (circa 2008) Visual Studio was your only real option.
But I'm on linux now. If I wanted to pick up back up then what should I be using?
- SurajMishra
For the features that overlap between golang and .Net, can someone please let me know why people choose .Net over golang for non legacy systems? As far as my limited knowledge goes, go is much more efficient in syntax and memory.