alt Hacker NewsAnnouncing .NET 11
Comments
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.
Microsoft is doing great things with C# and .NET but I feel like the OSS community is struggling with its culture and identity a bit. There has been a lot of rug pulling by some of the most popular open source packages in the .NET world in recent years.
First it was Identity Server, which Microsoft even recommend using in the official documentation (or at least did a year ago), which went closed source and switched names. Then there were others like MediatR and MassTransit who recently went commercial. And now, most recently, several packages are leaning into the "Open Source Maintenance Fee" model which is technically still open source but problematic for any who updates their nuget dependencies without reading all the documents included in the package. I think it hurts extra much because in many of these cases they were very much embraced not only by the community but also by Microsoft just like Identity Server. Like Polly is actually used as a dependency by official Microsoft packages after Microsoft decided to embrace it rather than replace it with their own implementation. Similarly MassTransit and other similar projects objected loudly a few years back when Microsoft were proposing their own messaging/eventing framework and Microsoft backed off.
I'm not saying that OSS maintainers and projects don't deserve to get paid, but none of these projects would have become nearly as popular had they started out commercial. And I feel like this type of thing is happening a lot more in the .NET community recently than in others (although I will concede that I am not as involved in others). Perhaps it is the fact that Microsoft as a big enterprise entity is very much in the driver's seat of the stack or the fact that it is used in a lot of enterprise software or just cultural baggage from 20 years ago where you paid for every library. In any case it feels like there is quite an Enterprise-y sentiment within the entire .NET community. Unfortunately.
https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
Be aware
(decimal)0.1
// .NET 10: 0.1
// .NET 11: 0.1000000000000000055511151231Ex-MSFT here. Some of MSFT’s biggest and high scale web services run on .NET Core on both Windows and Linux. I am speaking of services in Office, Security and Azure. Think across millions of VMs and servers. The tooling is great, the services are scalable. It’s nothing like .NET Framework.
MSFT’s own services run on .NET and it’s in their own interest to see it thrive and adopted even outside of MSFT.
My current employer, a mature US payroll company also runs on .NET core extensively and safe to say that the development is a breeze. Although I still find that I have to use a paid IDE like Rider or VS. The experience on VS code isn’t that mature.
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!
We've pragmatically switched all our apps to .NET MAUI and it's been a good ride.
Starting from native mobile apps, we shipped a Windows version as an add-on, and once feature-complete we switched the mobile native apps to the MAUI version.
The debugging phase has been surprisingly short and the app quality is on-par with native.
Too bad Apple never wanted to open Swift to Android, because now .NET MAUI is what Swift should have been.
DotNet finally has an official version manager! Check out dotnetup: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnetup...
C# and .NET are absolute joys to program in. To me they are a slightly more "enterprisey" Ruby on Rails but once you're in it there is a flow to it. Things fit very nicely together, especially with LINQ. Runtime code compilation/"scripting" with Roslyn Compiler Services et al is just great.
> .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).
I loved .NET, but it is slow. I abandoned it after I learned that it doesn't even compile to machine code, so it will never be fast.
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?
Does runtime async mean stackful coroutines? It's not obvious what exactly the state machines are replaced by, if not automatically inserted yield() calls.
C# is really good language with world class tooling
but job offers are kind of boring :/
My first job out of college was at Microsoft, probably at the height of its powers. I was a developer on the .NET team and helped bring SQLCLR to life, the regrettable decision to let you run .NET code inside SQL Server. That job opened a lot of interesting doors for me. The weather sucked though.
To all the .NET outsiders, C# is indeed the .NET darling but you can also use F# if you feel like living in the future. Or VB if you feel nostalgic. So in .Net land, C# is not destiny. It is a choice
My web browser is anxiously awaiting the "Performance Improvements in .NET 11" article.
I am looking forward to async stack traces being more legible. It might encourage developers to actually read and use them.
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.
I wonder what this means for custom async implementations in the long run. I was considering using my own AsyncBuilder to bring over a rudimentary "computation expression" capability. But that might be out of question now.
No mention of Avalonia. I remember it was chosen as a back-end for MAUI awhile ago.
Good news: dotnet does everything well Bad news: Microsoft
C# is a really great language, and I hope I can keep using it. I like Microsoft’s ecosystem, but personally, I’d like to see its cross-platform support strengthened a bit more.
C# finally has Sum types.
Not quite discriminated unions, but close. With an exhaustive checker with switch statements.
Now if only it made creating unique types easy, so I wouldn’t have to use a library like VOgen, the language would be nearly as good as F#
[dead]
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.
They have a section for breaking changes in .NET 11, containing a few dozen items. It starts with "If you're migrating an app to .NET 11", as if you'd ever have a choice. Microsoft forces you to upgrade every 2 years, and they ship breaking changes. It is completely unacceptable that these two coexist, and I'm confused why more people aren't angry about it.
Either you should not be forced to upgrade, or backward compatibility should be guaranteed -- not both. But Microsoft is happy to say "hey, we're going to completely abandon support for every version of .NET every 2 years, and if you can't keep up to date then everything that goes wrong is all your fault." Meanwhile, they have no problem breaking your code.
This essentially kills the possibility of just writing a bunch of small, useful libraries, and having them be useful forever. It is the antithesis of a healthy software ecosystem. Are you really expecting that every single open source library that is referenced by a reference of your references is going to be maintained in the face of breaking changes every 2 years? If not, then upgrading your version of .NET is just a gamble that things won't randomly break. But you must upgrade, or you're a bad developer who's leaving your apps vulnerable and every automated security checking system in the world will yell at you about how awful you are. You must upgrade everything you have ever written every two years, and hope that every library you've ever depended on does the same, or you are putting yourself at risk of some breaking change sneaking its way in, or leaving yourself vulnerable to a critical security issue that Microsoft refuses to back-apply.
I cannot understand why I'm the only one shouting from the rooftops about this. It's completely unacceptable to me.
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 looking to do AI with/on C#, I wrote about some of my experience with making codebases successful for AI[2].
[0] https://engineering.usemotion.com/moving-off-of-typescript-e...
[1] https://typescript-is-like-csharp.chrlschn.dev/
[2] https://chrlschn.dev/blog/2026/08/the-unexpected-ai-stack-cs...