I have a lot of respect for the .NET team. They often publish great in-depth articles and their pursuit for performance is relentless (e.g. see Kestrel and Entity Framework evolution).
And ASP.NET is one of the few large projects which managed to survive a large breaking changes. Almost to Python 2->3 level. You had to change how your web app behaved completely if you relied on their magic session which worked hard to keep state synched between back and front.
Feels good to have 3 trillion dollars interested in improving the stack you use and actually care.
Last time I tried Entity Framework it was slow. Replaced it with Dapper and a simple custom migration system. This took database validation and seeding from 10 seconds to less than 2 seconds during startup on low powered hardware with SQLite. The queries created by Entity had pointless cascade of multiple join statements.
I have been reaching for GO with simple tooling and HTTP back end. .NET is useful for other solutions.
I have had too many issues with their frameworks, like WPF, needing to implement Win32 hacks. Example, .Net 9 was the first Windows version that properly returns all network interfaces. Older runtimes only expose Enabled NICs. I still have to maintain Windows 7 support for some solutions.
I just went the other way and tore all my Dapper + SQL and repositories out of a big project and switched it all to EF Core 10. Not noticed any change in performance but dumped thousands of lines of unnecessary code. I like the tighter code, but you definitely do need to keep your eye on the "magic" of EF to avoid it doing anything goofy that isn't easily visible.
We use newer Entity Framework (Core) in a few large projects with zero issues.
Even have Dapper and moving away from it as it brings nothing to the table but strings and bunch of SQL.
ef core is great for simple queries and modification of your data while using the changetracker.
You can use AsNoTracking/Projection to perform similar like dapper for queries.
When using command query seperation you can also use dapper for queries and ef core for commands.
We are also running into more and more performance issues with EF. There are ways to tune it but I am not sure if it’s worth learning this for EF or if it’s not better to just go for straight SQL. Seems MS has this tendency to create abstractions that then don’t work 100%. I see this with .NET too. Often you have to go down to Win32 for apps that are tightly coupled with Windows and hardware.
I am not sure what the stats are but I am certain they left behind a huge number of projects. Probably a population that won't be very vocal on HN but that doesn't mean they don't exist.
Even for new projects there are problems I run into that force me to use 4.8. Like if you build an Excel formula, the mandatory async/await approach just doesn't work. It's not an asynchronous operation and runs into a UI context where you deadlock if you wait. They also broke a lot of the windows integration, where in a corporate environment the same network calls with the same syntax authenticate successfully with 4.8 but fail with core.
And because they broke backward compatibility on so many libraries, it's a non trivial effort to convert a complex code base to core.
It's great that they focus on performance, but the .net framework fossilised in term of functionality. It took like 15 years before they added a json serializer to the standard library, and don't even think about support for any new major image format (webp, heic). Everything has become complicated, there isn't a day where I don't see a crash message in visual studio. I used to be a big .net fan but I miss Anders' leadership.
On images... I think it might be best to handle a lot of it outside the core... possibly a nuget package that embeds ImageMagick, OptiPng and some other utilities for the purpose of image manipulation in general. The .Net experience itself has always been somewhat poor here.
As to the breaking changes... .Net Core 1.0 was nearly a decade ago... I understand that some people may want to continue running Windows 7 too, but eventually the world moves on and you either update or use a stale version.
The shift to Core and the breakup of a lot of bits comes down to the need to better support running on platforms outside windows... or, .Net itself would have likely died off completely. Most of the .Net projects I've worked on for close to a decade now have been deploying to Linux/Docker... If it weren't for Core/5+ as a shift, it would have been under another language/toolkit entirely.
> Like if you build an Excel formula, the mandatory async/await approach just doesn't work. It's not an asynchronous operation and runs into a UI context where you deadlock if you wait.
Last time I did excel interop it was COM based and there wasn't any async part of it. I'm curious if you were using COM interop also? Also, async/await was explicitly designed to work in UI contexts like Winforms and WPF where there is only a single UI thread...?
> It took like 15 years before they added a json serializer to the standard library..
That isn't really true. DataContractJsonSerializer [0] landed in .NET 3.5 which was in 2007. Admittedly, it kinda sucked but it was there and was usable. And also JSON.Net was around by that point and was/is excellent.
> ...and don't even think about support for any new major image format (webp, heic).
Image support on windows was historically provided by WIC [1] and does support the formats you talked about. But you are correct that native .NET support for many image formats is non-existent.
> And because they broke backward compatibility on so many libraries, it's a non trivial effort to convert a complex code base to core.
This is very true, and I felt it firsthand. My employer still has a codebase on .NET Framework (compiled against 4.5.2 but deployed against 4.8). It is WCF based and the jump to Core was a massive break. But in the end, I think the break was a good decision. There were just too many design mistakes, bad assumptions and underlying system changes to keep compat across the big leap to a modern multi-platform framework. .NET today is faster, more flexible and has more capabilities than .NET Framework ever did. Even if it did take a long time to get here.
And besides, even if new features are not coming to .NET Framework anymore, Microsoft has support .NET 3.5.1 until 2029! [2] Isn't 22 years of support enough? (.NET 4.8's EOL hasn't even been announced yet!)
For writing excel formulas, while I think you can use VSTO/COM, you will get a poor performance if you do. The "right" way to do it is with ExcelDNA/ManagedXLL. But the excel calculation engine was never designed to support async/await, and your calculations operate within a UI thread. So if you need to make a network call in one of your excel functions, you quickly run out of options.
RTD functions are a different thing. It may be useful for certain cases but in my usage would break the calculation model, as the calls must be made in a given order, and must be refreshed by the user deterministically. I can also build some more complex workaround, like calling a different process, though the antivirus in the corporate environment I work in is unlikely to like that.
Modern .NET is awesome. In a small side hustle project, I develop a REST API Backend in C# on my macOS using VSCode, and deploy it to Linux for the past 3 years without any issues. I use SQLite, EFCore, Minimal APIs and it is a delight compared to the frontend part - which is NextJS/React/MaterialUI with 50+ (dev-)packages in npm.
Would suggest taking a look at the FastEndpoints library if you need anything even slightly more complex... just about my favorite for APIs at this point.
A close second would be TS + Hono + Zod-OpenApi and SwaggerUI.. but setting up my context types is slightly more of a pain.
I used ServiceStack (also REST API) around ~2013 with C#. But in the end, a core benefit of .NET is that it is batteries-included, so I stick with the built-in Minimal API solution.
Plus, FastAPIs core selling point seems to be performance and speed - a solution to a problem that I don't currently have with that project, nor will encounter in the near future.
one thing that struck me was that the foundation for this effort was the linux distro build system. in other words, the work they put into making .net open-source and cross-platform eventually made everyone's lives easier.
We wanted the option for distro maintainers to include .NET in the native distro package feeds. This means that distro maintainers have to build the product, not us, and that means creating a build system that meets their requirements. So you either end up with two build systems, or you try and unify. The only direction that it's feasible to go is towards the Linux distro model. It's the most restrictive.
The good news is that the distro model is SIMPLER. It may not be the most performant. A really good distributed system with caching would be far faster. But that's not a solution that's easy to implement or compatible with distro maintainer workflows. Optimizing for simpler in this case is better though. We want the community to be able to participate in a meaningful way. Build for BSD, build for S390x, build and include in distro feeds, etc. We can't feasibly support every platform and scenario that the community wants.
I glad to read this. One of my long-term concerns with .NET, compared to other language ecosystems, is the risk that only Microsoft people might know how to build it and port it. Is any distro actually shipping .NET SDK packages built from source?
that sounds awesome. having wrestled with complex build setups I'm a big fan of simple and reproducible, though as you say there's definitely the temptation to do things to improve performance at the expense of simplicity.
I think .NET is way beyond the situation that they question their open source move. The amount of pull requests and positive outcomes for them in the last 10 years (yeah that long already) is mind blowing.
yeah, I didn't mean that it was evidence the open source move was successful or valuable, more that it showed that the engineering effort that went into the open sourcing also yielded dividends for the project in general
Oh, wow, I didn't expect that the best thing I'd read about software engineering, like, this year would come out of Microsoft! Don't get me wrong: I like .NET, especially its recent incarnation, but until just now, I would have expected its robustness to be an against-all-odds under-the-radar lucky escape from the general enshittification that seems to be the norm for the industry.
Reading something like this, which outlines a coordinated effort (diagrams and even a realistic use case for agentic LLM usage and all!) to actually and effectively make things better was a breath of fresh air, even if towards the end it notes that the remarkable investment in quality will not be in full force in the future.
Even if you don't care about .NET and/or Microsoft, this is worth reading, doubly so if you're in charge of re-engineering just about anything -- this is how it's done!
Nice article but it seems obvious to me the .NET team should throw away AzureDevOps as the queue wait time is the major bottleneck. Run bare metal build servers. Maybe there are justifications not to do this, but the article skips the elephant in the room.
Azure DevOps isn't the cause of the queue time problem. It can run bare metal. The Mac hardware that we run attaches and starts super quickly, for instance. We want clean machines on every job (for compliance and robustness), so we're spinning new VMs on Windows/Linux jobs.
We could have hot machines ready to go at all times and eliminate any queue time. There's also machine-learning based model for predictive spin-up. The downside is primarily cost to maintain all the various SKUs needed in a live and ready state. We compromise a bit there.
Why is Microsoft's developer division among the best in the industry while the rest of the company (except enterprise sales) is the literal embodiment of incompetence and enshittification? How have they prevented the pervasive cultural rot from affecting them?
Mostly due to politics and chasing the leaders in the industry. The days of looking in the mirror and seeing what they are have been gone since Bill left the job.
I can see that high level overviews of complex systems are useful to get some insights, but in the same way I have the feeling that this mentality of high level, abstract organization is the root of the problem. If you have a complex system and simplify the components into abstractions, you will repeatedly run into difficulties because you've actively ignored the dirty bits. It's an top down approach that tries to tackle all issues, but an bottom up approach could even eradicate myriads of issues.
No, read the article. It needs to build some "sub" SDKs to build the final 'full' SDK packages. That's the whole point; they want to get to a state where they can do that.
.NET was a solid choice for backend builds before Node became so popular (And .NET is generally more performant than Node).
I hope this churn in .NET builds is temporary because a lot of people might be looking to go back to something stable especially after the recent supply chain attacks on the Node ecosystem.
> I hope this churn in .NET builds is temporary because a lot of people might be looking to go back to something stable especially after the recent supply chain attacks on the Node ecosystem.
Can you elaborate a bit? This article talks about internal machinery of building .net releases. What does that have to do with "this churn", whatever that is?
My guess is if you build with .NET Framework you can just forever run your builds, but if your source code is based on newer .NET you have to update to a new version each year, and deal with all the work in upgrading your entire project, which also means everyone in your team is also upgrading their dev environment, and now you have new things in the language and the runtime to deal with, deprecation and all that. Plus lots of packages don’t update as fast when version changes occurs, so chances are you will probably take more work and use as few dependencies as possible if at all, which may cause a lot of work. Instead it’s best to, if you need to depend on something, to be a very big Swiss Army knife like thing.
I think node is just more flexible and unless .NET Framework like forever releases or much longer term support make a come back, there’s no good trade off from node, since you don’t even get more stability.
> if your source code is based on newer .NET you have to update to a new version each year
.NET has a really refreshingly sane release life cycle, similar to nodejs:
- There's a new major release every year (in November)
- Even numbers are LTS releases, and get 3 years of support/patches
- Odd numbers get 18 months of support/patches
This means if you target LTS, you have 2 years of support before the next LTS, and a full year overlap where both are supported. If you upgrade every release, you have at least 6 months of overlap
There's very few breaking changes between releases anyway, and it's often in infrastructure stuff (config, startup, project structure) as opposed to actual application code.
I think it's important to remember that Dotnet projects can use code built for older releases; to an almost absurd degree, and if you don't go to before the .NET Framework divide, you largely don't even need to change anything to move projects to newer frameworks. They largely just work.
The .Net platform is honestly the most stable it has ever been.
Recent experience report: I updated four of my team's five owned microservices to .net 10 over the past two weeks. All were previously on .net 8 or 9. The update was smooth: for the .net 9 services, I only had to update our base container images and the csproj target frameworks. For the .net 8 services, I also had to update the Mvc.Testing reference in their integration tests.
It's hard for me to imagine a version increment being much easier than this.
.NET Framework had back then, when it was not in frozen state as it is now, every release a list of breaking changes. Modern .NET breaking changes are not worth talking about. Keeping up with the state of the art however is more interesting... But that is needed to be a solution for today and to stay relevant.
AKA people who are willing to be honest about its faults. .NET has a lot of social commentary on how stable and robust it is yet for some reason in every project I've had the displeasure of brushing up against a .NET solution it's always "we're updating" and the update process magically takes longer than building the actual feature.
Or what is a pretty standard feature in other tech-stacks needs some bespoke solution that takes 3 dev cycles to implement... and of course there's going to be bugs.
And it's ALWAYS been this way. For some reason .NET has acolytes who have _always_ viewed .NET has the pinnacle of programming frameworks. .NET, Core, .NET framework, it doesn't matter.
You always get the same comments. For decades at the point.
Except the experience and outcomes don't match the claims.
Just before I get the reply, I'm pretty familiar with .NET since the 2000's.
What do you mean? The .Net ecosystem has been generalized chaos for the past 10 years.
A few years ago even most people actively working in .Net development couldn't tell what the hell was going on. It's better now. I distinctly recall when .Net Framework v4.8 had been released and a few months later .Net Core 3.0 came out and they announced that .Net Standard 2.0 was going to be the last version of that. Nobody had any idea what anything was.
.Net 5 helped a lot. Even then, MS has been releasing new versions of .Net at a breakneck pace. We're on .Net 10, and .Net Core 1.0 was 9 years ago. There's literally been a major version release every year for almost a decade. This is for a standard software framework! v10 is an LTS version of a software framework with all of 3 years of support. Yeah, it's only supported until 2028, and that's the LTS version.
The only chaos occurred in the transition from .NET Framework to .NET (Core). Upgrading .NET versions is mostly painless now because the breaking changes tend to only affect very specific cases. Should take a few minutes to upgrade for most people.
Except it is a bummer when one happens to have such specific cases.
It never takes a few minutes in big corp, everything has to be validated, the CI/CD pipelines updated, and now with .NET 10, IT has to clear permission to install VS 2026.
If you can't get permission to update/change IDE, the company processes aren't working at all tbh. Same if cicd is in another department that doesn't give a shit.
That is pretty standard in most Fortune 500, whose main business is not selling software, and most development is done via consulting agencies.
In many cases you get assigned virtual computers via Citrix/RDP/VNC, and there is a whole infra team responsible for handling tickets of the various contractors.
Similar story at my prior job. Heck, we still had one package that was only built using 32-bit .Net Framework 1.1. We were only just starting to see out-of-memory errors due to exhausting the 2 GB address space in ~2018.
I love the new features of .Net, but in my experience a lot of software written in .Net has very large code bases with a lot of customer specific modifications that must be supported. Those companies explicitly do not want their software framework moving major supported versions as quickly as .Net does right now, because they can't just say "oh, the new version should work just fine." They'd have to double or triple the team size just to handle all the re-validation.
Once again, I feel like I am begging HN to recognize not everyone is at a 25 person microservice startup.
I might be missing something but the combination of 'we mustn't break anything' and 'we can't test it without 2-3* team size' sounds like release deadlock until you can test it..
The migrations where I've worked at have always been a normal ticket/epic. You plan it in the release, you do the migration, you do the other features planned, do the system tests, fix everything broken, retest, fix, repeat until OK, release.
Otherwise you're hoping you know exactly how things interact and what can possibly have broken, and I doubt anyone knows that. Everyone's broken things at first sight seemingly completely unrelated to their changes at some point. Especially in large systems it happens constantly. Probably above 1% of our merges break the nightly in unexpected places since no one has the entire system in their head.
Or you're keeping a dead product just barely alive via surgical precision and a lot of prayers that the surgeon remains faultless prior to every release.
On the migrations... read the comments through this thread.. there are many, and none have mentioned any significant pain points at all, just hypothetical ones from people like you who aren't actually actively using it.
As to the CI/CD pipelines... I just edited my .github/workflow/* to bump the target version, and off to the races... though if you're deploying to bare metal as opposed to containers, it does take a couple extra steps.
As to the "permission to install..." that's what happens when companies don't trust the employees that already write the software that can make or break the company anyway... Defelopers should have local admin privs, or a jump box (rdp) that does... or at the very least a linux environment you can remote-develop on that, again, has local admin privs.
I'm in a locked down environment currently, for a govt agency and hasn't been an issue. Similar for past environments which include major banking institutions.
I have no idea about most .NET developers. At my current job (a public software company in US with thousands of employees) it's up to engineers to decide when to upgrade. We upgraded our main monolith app to .NET 10 in the first week.
I've been using .Net since late 2001 (ASP+) including in govt and banking and rarely have had issues getting timely updates for my local development environment, and in the past decade it's become more likely that the dev team controls the CI/CD environment and often the deployment server(s).... Though I prefer containerized apps over bare metal deployments.
Not sure about the past tense here. .NET is still excellent and getting even better with every release. What instability are you talking about? There was the leap to .NET Core which was majorly breaking, but that was almost 10 years ago now.
If they’re in a team similar to some I’ve worked with, engineers are barely getting comfortable with the shift away from .NET Framework (!)
There are legions of developers for whom Visual Studio on Windows is the only place they have ever been comfortable. And upgrading between versions of .NET is a point-click exercise between the various UIs (Visual Studio Installer, “Get New Components or Features”, and the NuGet package manager)
The advent of .NET Core happened to coincide with initiatives to adapt:
* toward the cloud and away from IIS and Windows Server
* toward Git and away from TFS
* toward remote CI/CD and away from “drag my files into inetpub”
* toward SPAs and away from ASP.NET XAML programming (Blazor notwithstanding)
* toward a broader toolkit where the familiarity with OSS and open specs is advantageous, and away from Visual Studio as the center of the universe (though it still arguably reigns supreme in its class of IDEs)
Coming from the Linux/Docker world before going deep in .NET, I was both resented and leaned on heavily for these teams’ transitions. Most of my teammates had never read the contents of their .csproj or .sln files, or run a build command from a terminal and read its log output. They were annoyed by my requests to do so when helping them troubleshoot; some just rejected the idea outright (“there’s no need to look at VS internals here”, “we shouldn’t need to run DOS commands in today’s world, VS should hable this!”)
I can definitely sympathize with developers who were sold on what seemed like a promise that deep VS/IIS/etc knowledge would be the rock-solid foundation for business software for the rest of their careers. During the uprooting process, other promises like “netstandard2.0 will be forever for your core libraries and all future .NET runtimes!” end up with asterisks the following year.
I am 100% in agreement that .NET dev team is doing an amazing job, but it’s precisely because of their continued shakeups when they see major opportunities to improve it from the ground up, and probably the same reason that others feel wary of it
Anyways, I work with .NET Framework and .NET. Being a developer is a joy where you can learn daily new tricks and satisfy your curiosity.
So to me this reads so alien that people fail to learn new tricks within .NET world. For me it's like a stream of amazement: Ohh, this is so much better with new language features. Ohh, this code is so much more clean. Woa, logging is so simple with ILogger and I can plug whatever underlying log engine I want! Configuration via JSON files, niice. I can override with Env variables out of the box? Amazing. This all follows particular rules and patterns. Ohh, I can customize the way I read configuration any way I want if I need it so. Ohh, I can build and run from CLI using simple commands! Ohh, I can package in docker and run on Linux. Oh, wow, .csproj is so much more clean, gotta use SDK-style project for my .NET Framework projects too!
I love it! And yeah .NET Framework is still critical for some workloads, most notably C++/CLI and WCF for certain apps where deep win32 APIs make their net8.0+ alternatives too much of a headache :)
To temper my comment, the resistance I faced as the new guy brought in to modernize is natural for these engineers who knew their tools and systems well, in their defense. Eventually they warmed up from full pushback to friendly banter “Mr. Linux and command line over here” and accepted that running my little scripts helped address the confusion/frustration of Visual Studio disagreeing with Jenkins/GitHub Actions automations and runtime behavior in Kubernetes.
Funny... I actually kind of hate ILogger... at least the output implementations I've seen. I really like line-delimited JSON for standard logging with a pretty-printed version for local dev. With say a node project, I will usually attach a few bits of context as well as a details object with the simple log message... this is easy enough to ship to another system, or say with AWS, the built in logging platform handles it brilliantly.
I haven't seen a good logger implementation for .Net that does a similar good job without a bunch of byzantine configurations.
You're totally right on all those changes, and I think all of those things were the bane of .NET development. Getting rid of all the cruft in one swift operation was life-changing. Finally being able to junk IIS and deploy web apps to Linux running their own tight little web server (Kestrel) is fantastic.
As someone who has actively pushed in the direction of containerized deployments, VS Code with the integrated terminal over VS proper, etc... I love the direction .Net has taken in general. I have worked in a few environments where most of the devs and projects themselves feel stuck in concrete. I've left a couple places like that in the past few years just because they are painful environments to work in.
I couldn't even tell you how to do certain things in the VS gui at this point... I've got Rider and VS installed only because Rider is nicer for refactoring and I've had to fix VS launch issues a couple times (VS backend, vite/react frontent).
Prior to .Net core I had one foot out the door, mostly towards Node... Now, I'm fine with either/both... though all my shell scripting is now with Deno/TS.
Since .Net Core 3, I haven't really experienced too many breaking issues that directly affected me... mostly been relatively easy to update my target framework and dependencies. I mean, it's slightly time consuming, but nothing like updating say a React project that's been sitting for even a couple years.
I know their release/LTS cycles are now much shorter than the 20+ years that some framework versions have seen, but keeping things "current" hasn't been that hard. IMO, it's just part of maintenance for "rapid" software development. Companies want software in weeks instead of many years of planning, that means ongoing maintenance work.
I feel the pain, as polyglot consultant, I would like to see more RFPs asking for .NET skills, unfortunely it seems it is all about nodejs, some Java, and plenty of low code tools (iPaaS).
At least exactly due to performance issues, I get some excuses to push for C++ addons in some cases.
>.NET was a solid choice for backend builds before Node became so popular
The problem with the community is that this statement has been said for every version in every era despite how untrue it is lol. No matter what ills or blights .NET will put on your solution the developers will always sing its real or imagined praises.
This is the #1 reason I avoid interacting and working with .NET teams because it's still true to this day.
I love working with dotnet, but lately I’ve been writing more backend applications in Python. The code is simpler, testing is simpler since method privacy doesn’t really exist, and code is quicker to deploy because you do not have to compile it.
This could also change but in my experience AI is better at generating Python code versus dotnet.
Problem is though Python is slow at runtime. May not matter for many use cases, but I've worked with a lot of startups that suffered terrible reliability problems because they chose Python (or Rails, or Node to some extent) and the service cannot handle peak time load without a lot of refactoring and additional app servers.
Depending on your framework Python is at best ~3x slower (FastAPI) and at worst ~20x (Django) than asp.net on the techempower benchmarks, which maps pretty well to my real world experience.
Can confirm. Just finished load testing a FastApi service. Now the biggest selling point is that a lot of real backend never experience the level of load where this actually matters
I work for a very large company that has a mostly SSR monolith written in PHP.
Modern PHP is a joy, and it's much faster these days, but performance is still a problem. It was chosen over 25 years ago, and I'm sure they thought the same thing about never getting the amount of load they eventually got.
Modern PHP is virtually indistinguishable from dotnet, with some php-isms sprinkled on top. They should've chosen dotnet all those years ago.
I don't spend a lot of time building services, but the last few I've done, I actually went straight to Rust. The downside is that it's quite slow to develop -- I probably don't have the knowledge that others do, but it seems that frameworks could really use some work. That said, I love that I can find and fix most my problems during development. Building a service in Python means I'm constantly fixing issues in production.
.NET is certainly better than Python, but I'm not very happy with the type system and the code organization versus my Rust projects.
You know, I tried F# like eight-ish years ago, and I loved it, but I couldn't break into doing it with enough regularity and depth that it made sense for me. I still do a decent amount of C# at work, and with my experience in Rust (algebraic data types, etc.), I imagine that F# would really help out a lot in our .NET code.
Not saying that it’s necessarily the right choice, but it opens up contributions to code to a broader user base and making those rapid iterations that tools like fastapi allow can be pretty important when proving out a concept early on.
Horses for courses… also, a Horizontal Pod Autoscaler and Load Balancer setup is pretty cheap.
I'm moving from Python to Java because of how much easier it is to actually use all CPU cores in Java and strict typing prevents so many bugs and it is much faster. I don't think it is actually that much more complicated than Python in 2025.
Agreed. It's sort of crazy how little people understand about multicore software design given nearly everyone is using machines with >8 CPU cores these days (even a cheap android phone tends to have 8 cpu cores these days).
In python and node it is _so_ painful to use multiple cores, whereas in .net you have parallel for loops and Task.WhenAll for over a decade. Java is similar in this sense that you don't have to do anything to use multiple cores and can just run multiple tasks without having to worry about passing state etc between 'workers'.
This actually becomes a really big problem for web performance, something I'm deeply passionate about. Not everything is just IO driven holdups, sometimes you do need to use a fair bit of CPU to solve a problem, and when you can't do it in parallel easily it ends up causing a lot of UX issues.
I am doing backend in Kotlin, but I must admit that Java has been catching up quickly, and it seems like Kotlin has been shifting its focus to Kotlin Multiplatform. Modern Java is a good, pleasant language and a safer bet.
Gradle with Kotlin DSL is nice, what's annoying is Gradle's constant API reshuffling for the sake of it that breaks plugins. Some plugins also introduce pointless breaking changes just to have a fancier DSL.
The IDE support is not an issue in practice, in my opinion, because IDEA is the best IDE for both Java and Kotlin. The official Kotlin LSP was released 6 months ago, but I haven't tried it.
I'm dabbling and like it but there is just SO MUCH JAVA code. There are 1000 Java examples for every 1 Kotlin. Maybe LLMs make this less of an issue now though.
Has too much sugar, and without JetBrains IDE you're stuck with a plain text editor. Not sure if it's generalizable to normal Kotlin or not, but learning Gradle Kotlin DSL made me want to rip my hair out when trying to understand what happens under the hood.
> Introduces a very messy and complex history which would not work for the repo of our size
> Apparently the support in git is buggy and can lead to problems in the repo (the SO is full of examples)
> Doesn't support cloaking
.NET has a far better developer experience than Node and is nearly as fast as Rust if written for performance, certainly much faster than Node or Python
Numbers are inflated not by choice but by force. Node is not a choice but a consequence of frontend heavy work. And JavaScript was made good using typescript by the guy who also created C#.
Same goes with Python with its data science and ML/AI background.
And the general malus is Microsoft as a company.
In summary: it is not the tech. It is the landscape.
Rust is a tool not for application development. It has a huge space in drivers, renderers and other low level places.
Node and Python are dynamically typed and at least originally scripting focused. They are not the right choice for many development active which are focused.
.NET plays with Go and Java in the same category of use cases. And there it boils down to devs you have.
Regards ecosystem: I am at home in both, .NET and JavaScript (browser more) and I can tell you: ecosystem is in 2025 no problem. Was back in the 2010s.
About the devs: you have what you have and hire along. Like Java, it will not go away. You get good ones and bad ones. Like for any other language.
Let us be less religious here. Objectively, .NET is like Go and Java a fit contender for its niche and selection goes along the lines what you have as workforce/systems already in place. In a startup situation you follow the preferences of your CTO.
I know where .NET fits: game development and legacy Windows apps. Otherwise, we don't need .NET—and let's not forget how HN feels when they have to deal with the MS tech stack.
You have absolutely no clue what you're talking about, mate. .NET is like Java. It's behind critical systems you haven't heard of because they're not flashy or glamorous, so you have no idea how prevalent they actually are.
The other posters are right. Most .NET projects today are backends, where it's used similarly to how Java is used.
I use c# also to earn my money. Sadly the new custom to hyperinflation in language sugar and framework makes following new things quite hard. Even today starting a new project I choose .net framework 3.5 and syntax. I know this sounds extreme but 3.5 has anything I need to build great software. It also offers a very tested environment. Setting up the software stack is a very easy process. Programmed following v2 runtime also work on v4 runtime so only a simple config file side by side to exe makes it run on any windows machine without any framework deployment.
.NET Framework 3.5 is so old it’s not available by default on Windows (maybe not available at all on the latest Windows), you’d probably have to work with ancient developer tooling to work with it, it’s probably unsupported and has security issues.
And that’s ignoring how you’re essentially severely handicapping yourself in terms of what is possible.
Unless you’re in an environment stuck 20 years in the past (which implies serious security liabilities considering they must be a Microsoft shop), this is a mind bogglingly bizarre strategy.
3.5 is approaching end of life in the next few years, you definitely should not building anything new with it. There's a lot of QoL changes in modern .NET that makes your life as a developer significantly nicer. Even for building windows services, the modern Generic Host model is orders of magnitude better than anything in .NET Framework.
I remember these days. But I have to say: .NET Core and .NET 5+ are awesome. They bring this ease you speak about into the cloud, into Linux, into containers. Obviously with the notable exception of UI development, but there the landscape has turned 5 times since 3.5 was released in 2007.
This is a strange take to me. I've been doing .NET for 25 years now. I don't see why you can't just write your code in "Framework 3.5" style in Visual Studio/VSCode 2026 with .NET 10? I would think almost any file from 3.5 would just drop in and compile with practically zero changes. I can't even think of any new language features that are being forced upon the developer.
Reminds me of an algorithms professor who'd get us to implement some modified standard algorithm in Java and then go over each implementation really quickly at the beginning of the next lecture. He'd find parts of your code weird, replace them really quickly and leave your clean, working implementation with 20 deprecation warnings.
At the end of the day both solutions/syntaxes work, but..
I have a lot of respect for the .NET team. They often publish great in-depth articles and their pursuit for performance is relentless (e.g. see Kestrel and Entity Framework evolution).
And ASP.NET is one of the few large projects which managed to survive a large breaking changes. Almost to Python 2->3 level. You had to change how your web app behaved completely if you relied on their magic session which worked hard to keep state synched between back and front.
Feels good to have 3 trillion dollars interested in improving the stack you use and actually care.
Developers! Developers! Developers!
Last time I tried Entity Framework it was slow. Replaced it with Dapper and a simple custom migration system. This took database validation and seeding from 10 seconds to less than 2 seconds during startup on low powered hardware with SQLite. The queries created by Entity had pointless cascade of multiple join statements.
I have been reaching for GO with simple tooling and HTTP back end. .NET is useful for other solutions.
I have had too many issues with their frameworks, like WPF, needing to implement Win32 hacks. Example, .Net 9 was the first Windows version that properly returns all network interfaces. Older runtimes only expose Enabled NICs. I still have to maintain Windows 7 support for some solutions.
I just went the other way and tore all my Dapper + SQL and repositories out of a big project and switched it all to EF Core 10. Not noticed any change in performance but dumped thousands of lines of unnecessary code. I like the tighter code, but you definitely do need to keep your eye on the "magic" of EF to avoid it doing anything goofy that isn't easily visible.
We use newer Entity Framework (Core) in a few large projects with zero issues. Even have Dapper and moving away from it as it brings nothing to the table but strings and bunch of SQL.
ef core is great for simple queries and modification of your data while using the changetracker. You can use AsNoTracking/Projection to perform similar like dapper for queries. When using command query seperation you can also use dapper for queries and ef core for commands.
We are also running into more and more performance issues with EF. There are ways to tune it but I am not sure if it’s worth learning this for EF or if it’s not better to just go for straight SQL. Seems MS has this tendency to create abstractions that then don’t work 100%. I see this with .NET too. Often you have to go down to Win32 for apps that are tightly coupled with Windows and hardware.
Are you talking about EF or EF Core? If the later, did you enable any or all of the magic like automatic property evaluation/eager fetching etc.?
EFCore by default is pretty performant - and pretty basic. You need to manually .Include() joins etc. which makes it pretty hard to become slow.
EF Core. It’s fine to some degree but larger queries with lots of joins can get very slow. Not all but just some of them.
Is not that the core problem with ORMs. All of them. In the end you do straight SQL when it comes to Performance.
[dead]
The trick with EF Core is to let it do the simple stuff and if you need anything more complicated than .Include write the query yourself.
What version was it?
I am not sure what the stats are but I am certain they left behind a huge number of projects. Probably a population that won't be very vocal on HN but that doesn't mean they don't exist.
Even for new projects there are problems I run into that force me to use 4.8. Like if you build an Excel formula, the mandatory async/await approach just doesn't work. It's not an asynchronous operation and runs into a UI context where you deadlock if you wait. They also broke a lot of the windows integration, where in a corporate environment the same network calls with the same syntax authenticate successfully with 4.8 but fail with core.
And because they broke backward compatibility on so many libraries, it's a non trivial effort to convert a complex code base to core.
It's great that they focus on performance, but the .net framework fossilised in term of functionality. It took like 15 years before they added a json serializer to the standard library, and don't even think about support for any new major image format (webp, heic). Everything has become complicated, there isn't a day where I don't see a crash message in visual studio. I used to be a big .net fan but I miss Anders' leadership.
On images... I think it might be best to handle a lot of it outside the core... possibly a nuget package that embeds ImageMagick, OptiPng and some other utilities for the purpose of image manipulation in general. The .Net experience itself has always been somewhat poor here.
As to the breaking changes... .Net Core 1.0 was nearly a decade ago... I understand that some people may want to continue running Windows 7 too, but eventually the world moves on and you either update or use a stale version.
The shift to Core and the breakup of a lot of bits comes down to the need to better support running on platforms outside windows... or, .Net itself would have likely died off completely. Most of the .Net projects I've worked on for close to a decade now have been deploying to Linux/Docker... If it weren't for Core/5+ as a shift, it would have been under another language/toolkit entirely.
> Like if you build an Excel formula, the mandatory async/await approach just doesn't work. It's not an asynchronous operation and runs into a UI context where you deadlock if you wait.
Last time I did excel interop it was COM based and there wasn't any async part of it. I'm curious if you were using COM interop also? Also, async/await was explicitly designed to work in UI contexts like Winforms and WPF where there is only a single UI thread...?
> It took like 15 years before they added a json serializer to the standard library..
That isn't really true. DataContractJsonSerializer [0] landed in .NET 3.5 which was in 2007. Admittedly, it kinda sucked but it was there and was usable. And also JSON.Net was around by that point and was/is excellent.
> ...and don't even think about support for any new major image format (webp, heic).
Image support on windows was historically provided by WIC [1] and does support the formats you talked about. But you are correct that native .NET support for many image formats is non-existent.
> And because they broke backward compatibility on so many libraries, it's a non trivial effort to convert a complex code base to core.
This is very true, and I felt it firsthand. My employer still has a codebase on .NET Framework (compiled against 4.5.2 but deployed against 4.8). It is WCF based and the jump to Core was a massive break. But in the end, I think the break was a good decision. There were just too many design mistakes, bad assumptions and underlying system changes to keep compat across the big leap to a modern multi-platform framework. .NET today is faster, more flexible and has more capabilities than .NET Framework ever did. Even if it did take a long time to get here.
And besides, even if new features are not coming to .NET Framework anymore, Microsoft has support .NET 3.5.1 until 2029! [2] Isn't 22 years of support enough? (.NET 4.8's EOL hasn't even been announced yet!)
[0] https://learn.microsoft.com/en-us/dotnet/api/system.runtime.... [1] https://learn.microsoft.com/en-us/windows/win32/wic/native-w... [2] https://learn.microsoft.com/en-us/lifecycle/products/microso...
For writing excel formulas, while I think you can use VSTO/COM, you will get a poor performance if you do. The "right" way to do it is with ExcelDNA/ManagedXLL. But the excel calculation engine was never designed to support async/await, and your calculations operate within a UI thread. So if you need to make a network call in one of your excel functions, you quickly run out of options.
4.8 is basically never going away. its built into Windows thanks to Longhorn developers, many of whom left mid project to work at Google.
async await works fine to build Excel formulas via RTD Servers. https://excel-dna.net/docs/release-notes-1-9/#asynchronous-a...
Just because you think something is hard, doesn't mean it is hard.
RTD functions are a different thing. It may be useful for certain cases but in my usage would break the calculation model, as the calls must be made in a given order, and must be refreshed by the user deterministically. I can also build some more complex workaround, like calling a different process, though the antivirus in the corporate environment I work in is unlikely to like that.
[dead]
[flagged]
Modern .NET is awesome. In a small side hustle project, I develop a REST API Backend in C# on my macOS using VSCode, and deploy it to Linux for the past 3 years without any issues. I use SQLite, EFCore, Minimal APIs and it is a delight compared to the frontend part - which is NextJS/React/MaterialUI with 50+ (dev-)packages in npm.
Would suggest taking a look at the FastEndpoints library if you need anything even slightly more complex... just about my favorite for APIs at this point.
A close second would be TS + Hono + Zod-OpenApi and SwaggerUI.. but setting up my context types is slightly more of a pain.
I used ServiceStack (also REST API) around ~2013 with C#. But in the end, a core benefit of .NET is that it is batteries-included, so I stick with the built-in Minimal API solution.
Plus, FastAPIs core selling point seems to be performance and speed - a solution to a problem that I don't currently have with that project, nor will encounter in the near future.
one thing that struck me was that the foundation for this effort was the linux distro build system. in other words, the work they put into making .net open-source and cross-platform eventually made everyone's lives easier.
Author of the post here,
We wanted the option for distro maintainers to include .NET in the native distro package feeds. This means that distro maintainers have to build the product, not us, and that means creating a build system that meets their requirements. So you either end up with two build systems, or you try and unify. The only direction that it's feasible to go is towards the Linux distro model. It's the most restrictive.
The good news is that the distro model is SIMPLER. It may not be the most performant. A really good distributed system with caching would be far faster. But that's not a solution that's easy to implement or compatible with distro maintainer workflows. Optimizing for simpler in this case is better though. We want the community to be able to participate in a meaningful way. Build for BSD, build for S390x, build and include in distro feeds, etc. We can't feasibly support every platform and scenario that the community wants.
I glad to read this. One of my long-term concerns with .NET, compared to other language ecosystems, is the risk that only Microsoft people might know how to build it and port it. Is any distro actually shipping .NET SDK packages built from source?
Yes, Canonical, RedHat, Fedora, Alpine, Centos, and Arch Linux. NixOS and nixpackages too.
Looks like I missed progress during the time I've been away from dotnet, thanks. I still had memories of having to install an MS repo for that.
"old man yells at clouds." :)
Not at all! Looking at the package dates, distros have started shipping their own source builds during 2022-2024, starting with .NET 6-7.
Yes - Ubuntu, Alpine, Fedora, and others. [1]
[1]: https://github.com/dotnet/source-build/blob/main/README.md#n...
Thanks for the reference. I had memories of having to install a Microsoft repository to install the SDK, that's an improvement.
that sounds awesome. having wrestled with complex build setups I'm a big fan of simple and reproducible, though as you say there's definitely the temptation to do things to improve performance at the expense of simplicity.
I think .NET is way beyond the situation that they question their open source move. The amount of pull requests and positive outcomes for them in the last 10 years (yeah that long already) is mind blowing.
yeah, I didn't mean that it was evidence the open source move was successful or valuable, more that it showed that the engineering effort that went into the open sourcing also yielded dividends for the project in general
Oh, wow, I didn't expect that the best thing I'd read about software engineering, like, this year would come out of Microsoft! Don't get me wrong: I like .NET, especially its recent incarnation, but until just now, I would have expected its robustness to be an against-all-odds under-the-radar lucky escape from the general enshittification that seems to be the norm for the industry.
Reading something like this, which outlines a coordinated effort (diagrams and even a realistic use case for agentic LLM usage and all!) to actually and effectively make things better was a breath of fresh air, even if towards the end it notes that the remarkable investment in quality will not be in full force in the future.
Even if you don't care about .NET and/or Microsoft, this is worth reading, doubly so if you're in charge of re-engineering just about anything -- this is how it's done!
Must have been an amazing effort to be involved in.
Nice article but it seems obvious to me the .NET team should throw away AzureDevOps as the queue wait time is the major bottleneck. Run bare metal build servers. Maybe there are justifications not to do this, but the article skips the elephant in the room.
Azure DevOps isn't the cause of the queue time problem. It can run bare metal. The Mac hardware that we run attaches and starts super quickly, for instance. We want clean machines on every job (for compliance and robustness), so we're spinning new VMs on Windows/Linux jobs.
We could have hot machines ready to go at all times and eliminate any queue time. There's also machine-learning based model for predictive spin-up. The downside is primarily cost to maintain all the various SKUs needed in a live and ready state. We compromise a bit there.
Why is Microsoft's developer division among the best in the industry while the rest of the company (except enterprise sales) is the literal embodiment of incompetence and enshittification? How have they prevented the pervasive cultural rot from affecting them?
Mostly due to politics and chasing the leaders in the industry. The days of looking in the mirror and seeing what they are have been gone since Bill left the job.
I can see that high level overviews of complex systems are useful to get some insights, but in the same way I have the feeling that this mentality of high level, abstract organization is the root of the problem. If you have a complex system and simplify the components into abstractions, you will repeatedly run into difficulties because you've actively ignored the dirty bits. It's an top down approach that tries to tackle all issues, but an bottom up approach could even eradicate myriads of issues.
> We’re asking how much it will cost to build 3-4 major versions with a dozen .NET SDK bands between them each month.
Why so many variants?
Well you've got .NET 8 (LTS), .NET 9 (standard support), .NET 10 (LTS). These are all supported at once.
Then you've got the .NET SDK/aspnet/runtime (on x64/arm32/arm64 linux/mac/windows), and also the various SDK packages themselves.
3**4 = 81 builds - but aren’t all of those independent and thus parallelizable?
No, read the article. It needs to build some "sub" SDKs to build the final 'full' SDK packages. That's the whole point; they want to get to a state where they can do that.
.NET was a solid choice for backend builds before Node became so popular (And .NET is generally more performant than Node).
I hope this churn in .NET builds is temporary because a lot of people might be looking to go back to something stable especially after the recent supply chain attacks on the Node ecosystem.
> I hope this churn in .NET builds is temporary because a lot of people might be looking to go back to something stable especially after the recent supply chain attacks on the Node ecosystem.
Can you elaborate a bit? This article talks about internal machinery of building .net releases. What does that have to do with "this churn", whatever that is?
My guess is if you build with .NET Framework you can just forever run your builds, but if your source code is based on newer .NET you have to update to a new version each year, and deal with all the work in upgrading your entire project, which also means everyone in your team is also upgrading their dev environment, and now you have new things in the language and the runtime to deal with, deprecation and all that. Plus lots of packages don’t update as fast when version changes occurs, so chances are you will probably take more work and use as few dependencies as possible if at all, which may cause a lot of work. Instead it’s best to, if you need to depend on something, to be a very big Swiss Army knife like thing.
I think node is just more flexible and unless .NET Framework like forever releases or much longer term support make a come back, there’s no good trade off from node, since you don’t even get more stability.
> if your source code is based on newer .NET you have to update to a new version each year
.NET has a really refreshingly sane release life cycle, similar to nodejs:
- There's a new major release every year (in November)
- Even numbers are LTS releases, and get 3 years of support/patches
- Odd numbers get 18 months of support/patches
This means if you target LTS, you have 2 years of support before the next LTS, and a full year overlap where both are supported. If you upgrade every release, you have at least 6 months of overlap
There's very few breaking changes between releases anyway, and it's often in infrastructure stuff (config, startup, project structure) as opposed to actual application code.
> Odd numbers get 18 months of support/patches
The recently fixed the friction with odd number releases by providing 24 months of support.
Ah, but if you use node.js you get breaking changes every other day from dependencies on dependencies you didn’t even know you had.
The in the box libraries for .Net (even if via Nuget) are much more stable by comparison.
I think it's important to remember that Dotnet projects can use code built for older releases; to an almost absurd degree, and if you don't go to before the .NET Framework divide, you largely don't even need to change anything to move projects to newer frameworks. They largely just work.
The .Net platform is honestly the most stable it has ever been.
Going from Core 1 to 2 then 3 had a lot of rough edges, but since then it's been pretty painless.
Recent experience report: I updated four of my team's five owned microservices to .net 10 over the past two weeks. All were previously on .net 8 or 9. The update was smooth: for the .net 9 services, I only had to update our base container images and the csproj target frameworks. For the .net 8 services, I also had to update the Mvc.Testing reference in their integration tests.
It's hard for me to imagine a version increment being much easier than this.
I'm currently migrating dozens of projects to .NET 10. All of them so far were basically one line changes and a recompile.
You should be able to go from .NET 6->10 without almost any changes at all.
The past three years of dotnet upgrades have been completely painless for me.
.NET Framework had back then, when it was not in frozen state as it is now, every release a list of breaking changes. Modern .NET breaking changes are not worth talking about. Keeping up with the state of the art however is more interesting... But that is needed to be a solution for today and to stay relevant.
Note how practitioners of .NET praise it and non-practitioners (users of .NET Framework) criticize it.
Or users of other programming tool chains.
AKA people who are willing to be honest about its faults. .NET has a lot of social commentary on how stable and robust it is yet for some reason in every project I've had the displeasure of brushing up against a .NET solution it's always "we're updating" and the update process magically takes longer than building the actual feature.
Or what is a pretty standard feature in other tech-stacks needs some bespoke solution that takes 3 dev cycles to implement... and of course there's going to be bugs.
And it's ALWAYS been this way. For some reason .NET has acolytes who have _always_ viewed .NET has the pinnacle of programming frameworks. .NET, Core, .NET framework, it doesn't matter.
You always get the same comments. For decades at the point.
Except the experience and outcomes don't match the claims.
Just before I get the reply, I'm pretty familiar with .NET since the 2000's.
What do you mean? The .Net ecosystem has been generalized chaos for the past 10 years.
A few years ago even most people actively working in .Net development couldn't tell what the hell was going on. It's better now. I distinctly recall when .Net Framework v4.8 had been released and a few months later .Net Core 3.0 came out and they announced that .Net Standard 2.0 was going to be the last version of that. Nobody had any idea what anything was.
.Net 5 helped a lot. Even then, MS has been releasing new versions of .Net at a breakneck pace. We're on .Net 10, and .Net Core 1.0 was 9 years ago. There's literally been a major version release every year for almost a decade. This is for a standard software framework! v10 is an LTS version of a software framework with all of 3 years of support. Yeah, it's only supported until 2028, and that's the LTS version.
The only chaos occurred in the transition from .NET Framework to .NET (Core). Upgrading .NET versions is mostly painless now because the breaking changes tend to only affect very specific cases. Should take a few minutes to upgrade for most people.
Except it is a bummer when one happens to have such specific cases.
It never takes a few minutes in big corp, everything has to be validated, the CI/CD pipelines updated, and now with .NET 10, IT has to clear permission to install VS 2026.
If you can't get permission to update/change IDE, the company processes aren't working at all tbh. Same if cicd is in another department that doesn't give a shit.
That is pretty standard in most Fortune 500, whose main business is not selling software, and most development is done via consulting agencies.
In many cases you get assigned virtual computers via Citrix/RDP/VNC, and there is a whole infra team responsible for handling tickets of the various contractors.
Similar story at my prior job. Heck, we still had one package that was only built using 32-bit .Net Framework 1.1. We were only just starting to see out-of-memory errors due to exhausting the 2 GB address space in ~2018.
I love the new features of .Net, but in my experience a lot of software written in .Net has very large code bases with a lot of customer specific modifications that must be supported. Those companies explicitly do not want their software framework moving major supported versions as quickly as .Net does right now, because they can't just say "oh, the new version should work just fine." They'd have to double or triple the team size just to handle all the re-validation.
Once again, I feel like I am begging HN to recognize not everyone is at a 25 person microservice startup.
I might be missing something but the combination of 'we mustn't break anything' and 'we can't test it without 2-3* team size' sounds like release deadlock until you can test it..
The migrations where I've worked at have always been a normal ticket/epic. You plan it in the release, you do the migration, you do the other features planned, do the system tests, fix everything broken, retest, fix, repeat until OK, release.
Otherwise you're hoping you know exactly how things interact and what can possibly have broken, and I doubt anyone knows that. Everyone's broken things at first sight seemingly completely unrelated to their changes at some point. Especially in large systems it happens constantly. Probably above 1% of our merges break the nightly in unexpected places since no one has the entire system in their head.
Or you're keeping a dead product just barely alive via surgical precision and a lot of prayers that the surgeon remains faultless prior to every release.
On the migrations... read the comments through this thread.. there are many, and none have mentioned any significant pain points at all, just hypothetical ones from people like you who aren't actually actively using it.
As to the CI/CD pipelines... I just edited my .github/workflow/* to bump the target version, and off to the races... though if you're deploying to bare metal as opposed to containers, it does take a couple extra steps.
As to the "permission to install..." that's what happens when companies don't trust the employees that already write the software that can make or break the company anyway... Defelopers should have local admin privs, or a jump box (rdp) that does... or at the very least a linux environment you can remote-develop on that, again, has local admin privs.
I'm in a locked down environment currently, for a govt agency and hasn't been an issue. Similar for past environments which include major banking institutions.
Each one is their own anecdote.
You're describing a specific case of working in a big rigid enterprise. It doesn't have anything to do with .NET itself, does it?
Guess where most .NET developers employeers happen to be?
I have no idea about most .NET developers. At my current job (a public software company in US with thousands of employees) it's up to engineers to decide when to upgrade. We upgraded our main monolith app to .NET 10 in the first week.
For me, customers IT and their management decides.
I've been using .Net since late 2001 (ASP+) including in govt and banking and rarely have had issues getting timely updates for my local development environment, and in the past decade it's become more likely that the dev team controls the CI/CD environment and often the deployment server(s).... Though I prefer containerized apps over bare metal deployments.
Some devs get lucky.
Not sure about the past tense here. .NET is still excellent and getting even better with every release. What instability are you talking about? There was the leap to .NET Core which was majorly breaking, but that was almost 10 years ago now.
If they’re in a team similar to some I’ve worked with, engineers are barely getting comfortable with the shift away from .NET Framework (!)
There are legions of developers for whom Visual Studio on Windows is the only place they have ever been comfortable. And upgrading between versions of .NET is a point-click exercise between the various UIs (Visual Studio Installer, “Get New Components or Features”, and the NuGet package manager)
The advent of .NET Core happened to coincide with initiatives to adapt:
* toward the cloud and away from IIS and Windows Server
* toward Git and away from TFS
* toward remote CI/CD and away from “drag my files into inetpub”
* toward SPAs and away from ASP.NET XAML programming (Blazor notwithstanding)
* toward a broader toolkit where the familiarity with OSS and open specs is advantageous, and away from Visual Studio as the center of the universe (though it still arguably reigns supreme in its class of IDEs)
Coming from the Linux/Docker world before going deep in .NET, I was both resented and leaned on heavily for these teams’ transitions. Most of my teammates had never read the contents of their .csproj or .sln files, or run a build command from a terminal and read its log output. They were annoyed by my requests to do so when helping them troubleshoot; some just rejected the idea outright (“there’s no need to look at VS internals here”, “we shouldn’t need to run DOS commands in today’s world, VS should hable this!”)
I can definitely sympathize with developers who were sold on what seemed like a promise that deep VS/IIS/etc knowledge would be the rock-solid foundation for business software for the rest of their careers. During the uprooting process, other promises like “netstandard2.0 will be forever for your core libraries and all future .NET runtimes!” end up with asterisks the following year.
I am 100% in agreement that .NET dev team is doing an amazing job, but it’s precisely because of their continued shakeups when they see major opportunities to improve it from the ground up, and probably the same reason that others feel wary of it
Thanks for making me feel like a 10x dev :)
Anyways, I work with .NET Framework and .NET. Being a developer is a joy where you can learn daily new tricks and satisfy your curiosity.
So to me this reads so alien that people fail to learn new tricks within .NET world. For me it's like a stream of amazement: Ohh, this is so much better with new language features. Ohh, this code is so much more clean. Woa, logging is so simple with ILogger and I can plug whatever underlying log engine I want! Configuration via JSON files, niice. I can override with Env variables out of the box? Amazing. This all follows particular rules and patterns. Ohh, I can customize the way I read configuration any way I want if I need it so. Ohh, I can build and run from CLI using simple commands! Ohh, I can package in docker and run on Linux. Oh, wow, .csproj is so much more clean, gotta use SDK-style project for my .NET Framework projects too!
I love it! And yeah .NET Framework is still critical for some workloads, most notably C++/CLI and WCF for certain apps where deep win32 APIs make their net8.0+ alternatives too much of a headache :)
To temper my comment, the resistance I faced as the new guy brought in to modernize is natural for these engineers who knew their tools and systems well, in their defense. Eventually they warmed up from full pushback to friendly banter “Mr. Linux and command line over here” and accepted that running my little scripts helped address the confusion/frustration of Visual Studio disagreeing with Jenkins/GitHub Actions automations and runtime behavior in Kubernetes.
Funny... I actually kind of hate ILogger... at least the output implementations I've seen. I really like line-delimited JSON for standard logging with a pretty-printed version for local dev. With say a node project, I will usually attach a few bits of context as well as a details object with the simple log message... this is easy enough to ship to another system, or say with AWS, the built in logging platform handles it brilliantly.
I haven't seen a good logger implementation for .Net that does a similar good job without a bunch of byzantine configurations.
You're totally right on all those changes, and I think all of those things were the bane of .NET development. Getting rid of all the cruft in one swift operation was life-changing. Finally being able to junk IIS and deploy web apps to Linux running their own tight little web server (Kestrel) is fantastic.
As someone who has actively pushed in the direction of containerized deployments, VS Code with the integrated terminal over VS proper, etc... I love the direction .Net has taken in general. I have worked in a few environments where most of the devs and projects themselves feel stuck in concrete. I've left a couple places like that in the past few years just because they are painful environments to work in.
I couldn't even tell you how to do certain things in the VS gui at this point... I've got Rider and VS installed only because Rider is nicer for refactoring and I've had to fix VS launch issues a couple times (VS backend, vite/react frontent).
Prior to .Net core I had one foot out the door, mostly towards Node... Now, I'm fine with either/both... though all my shell scripting is now with Deno/TS.
I love C#. When combined with JetBrains Rider it may be the most satisfying dev experience I’ve had in my career.
Since .Net Core 3, I haven't really experienced too many breaking issues that directly affected me... mostly been relatively easy to update my target framework and dependencies. I mean, it's slightly time consuming, but nothing like updating say a React project that's been sitting for even a couple years.
I know their release/LTS cycles are now much shorter than the 20+ years that some framework versions have seen, but keeping things "current" hasn't been that hard. IMO, it's just part of maintenance for "rapid" software development. Companies want software in weeks instead of many years of planning, that means ongoing maintenance work.
I feel the pain, as polyglot consultant, I would like to see more RFPs asking for .NET skills, unfortunely it seems it is all about nodejs, some Java, and plenty of low code tools (iPaaS).
At least exactly due to performance issues, I get some excuses to push for C++ addons in some cases.
.NET churns less than any other major stack. Every upgrade since Core 2 (released in 2017) has been minimally painful or, more recently, painless.
Similar for me, though I had a lot of pain going from Core 2 to Core 3... a couple minor hiccups with .Net 5, but since then nothing of note.
>.NET was a solid choice for backend builds before Node became so popular
The problem with the community is that this statement has been said for every version in every era despite how untrue it is lol. No matter what ills or blights .NET will put on your solution the developers will always sing its real or imagined praises.
This is the #1 reason I avoid interacting and working with .NET teams because it's still true to this day.
Honesty would go a long way.
I love working with dotnet, but lately I’ve been writing more backend applications in Python. The code is simpler, testing is simpler since method privacy doesn’t really exist, and code is quicker to deploy because you do not have to compile it.
This could also change but in my experience AI is better at generating Python code versus dotnet.
Problem is though Python is slow at runtime. May not matter for many use cases, but I've worked with a lot of startups that suffered terrible reliability problems because they chose Python (or Rails, or Node to some extent) and the service cannot handle peak time load without a lot of refactoring and additional app servers.
Depending on your framework Python is at best ~3x slower (FastAPI) and at worst ~20x (Django) than asp.net on the techempower benchmarks, which maps pretty well to my real world experience.
Can confirm. Just finished load testing a FastApi service. Now the biggest selling point is that a lot of real backend never experience the level of load where this actually matters
I work for a very large company that has a mostly SSR monolith written in PHP.
Modern PHP is a joy, and it's much faster these days, but performance is still a problem. It was chosen over 25 years ago, and I'm sure they thought the same thing about never getting the amount of load they eventually got.
Modern PHP is virtually indistinguishable from dotnet, with some php-isms sprinkled on top. They should've chosen dotnet all those years ago.
I don't spend a lot of time building services, but the last few I've done, I actually went straight to Rust. The downside is that it's quite slow to develop -- I probably don't have the knowledge that others do, but it seems that frameworks could really use some work. That said, I love that I can find and fix most my problems during development. Building a service in Python means I'm constantly fixing issues in production.
.NET is certainly better than Python, but I'm not very happy with the type system and the code organization versus my Rust projects.
> .NET is certainly better than Python, but I'm not very happy with the type system and the code organization versus my Rust projects.
Have you given F# a whirl?
You know, I tried F# like eight-ish years ago, and I loved it, but I couldn't break into doing it with enough regularity and depth that it made sense for me. I still do a decent amount of C# at work, and with my experience in Rust (algebraic data types, etc.), I imagine that F# would really help out a lot in our .NET code.
Take a look at FastEndpoints library for API development... definitely improves the experience a lot IMO...
That said, Rust+Axum is pretty nice as well.
Not saying that it’s necessarily the right choice, but it opens up contributions to code to a broader user base and making those rapid iterations that tools like fastapi allow can be pretty important when proving out a concept early on.
Horses for courses… also, a Horizontal Pod Autoscaler and Load Balancer setup is pretty cheap.
Most web apps are waiting on the DB anyway. Rarely have I seen the speed of the actual framework make any meaningful difference.
If you don't want your methods to be private make them public?
Just make them internal and use [InternalsVisibleTo] on the assembly.
I'm moving from Python to Java because of how much easier it is to actually use all CPU cores in Java and strict typing prevents so many bugs and it is much faster. I don't think it is actually that much more complicated than Python in 2025.
Agreed. It's sort of crazy how little people understand about multicore software design given nearly everyone is using machines with >8 CPU cores these days (even a cheap android phone tends to have 8 cpu cores these days).
In python and node it is _so_ painful to use multiple cores, whereas in .net you have parallel for loops and Task.WhenAll for over a decade. Java is similar in this sense that you don't have to do anything to use multiple cores and can just run multiple tasks without having to worry about passing state etc between 'workers'.
This actually becomes a really big problem for web performance, something I'm deeply passionate about. Not everything is just IO driven holdups, sometimes you do need to use a fair bit of CPU to solve a problem, and when you can't do it in parallel easily it ends up causing a lot of UX issues.
On most cloud deployments, you get one shared “virtual” core — whatever that means.
No you get how ever many you choose and are willing to pay for. 1vCPU is not good for very much.
Even Guido van Rossum admits that if he had known how common high core count CPUs would become he wouldn't have chosen to use the GIL
That’s one reason I’ve preferred .Net. Put ahead of time compilation on top and it is glorious.
out of curiosity, why not kotlin? I had the impression it was the jvm language to reach for by default these days.
I am doing backend in Kotlin, but I must admit that Java has been catching up quickly, and it seems like Kotlin has been shifting its focus to Kotlin Multiplatform. Modern Java is a good, pleasant language and a safer bet.
Gradle with Kotlin DSL is nice, what's annoying is Gradle's constant API reshuffling for the sake of it that breaks plugins. Some plugins also introduce pointless breaking changes just to have a fancier DSL.
The IDE support is not an issue in practice, in my opinion, because IDEA is the best IDE for both Java and Kotlin. The official Kotlin LSP was released 6 months ago, but I haven't tried it.
I'm dabbling and like it but there is just SO MUCH JAVA code. There are 1000 Java examples for every 1 Kotlin. Maybe LLMs make this less of an issue now though.
Has too much sugar, and without JetBrains IDE you're stuck with a plain text editor. Not sure if it's generalizable to normal Kotlin or not, but learning Gradle Kotlin DSL made me want to rip my hair out when trying to understand what happens under the hood.
Is nuget any different from npm
It is, shall we say, more curated
It has the benefit of being late to the game (like .NET was to Java).
This isn't really anything user facing. It's just yet again an example of why monorepos are better.
Anything is a monorepo if you submodule hard enough lol
Why don't people use subtree?
https://www.atlassian.com/git/tutorials/git-subtree
The .NET source build team looked at subtrees (https://github.com/dotnet/arcade/issues/10257#issuecomment-1...).
> Introduces a very messy and complex history which would not work for the repo of our size > Apparently the support in git is buggy and can lead to problems in the repo (the SO is full of examples) > Doesn't support cloaking
(I think by "cloaking" they are referring to https://github.com/premun/dotnet/blob/766c564dd379e634c38739... )
.Net need a "node" level of developer experience and perfomance of rust/zig since node/python ecosystem rewrite make it more perfomance than ever
I cant see .net win againts those odds tbh
.NET has a far better developer experience than Node and is nearly as fast as Rust if written for performance, certainly much faster than Node or Python
numbers speak for themselves
Numbers are inflated not by choice but by force. Node is not a choice but a consequence of frontend heavy work. And JavaScript was made good using typescript by the guy who also created C#.
Same goes with Python with its data science and ML/AI background.
And the general malus is Microsoft as a company.
In summary: it is not the tech. It is the landscape.
TS is still much more annoying to use than monotonically typed systems like dotnet, and it's also much less safe.
TS drags JS into the world of modern languages, but it's not good enough IMO.
Would you mind providing yours as well as benchmarks used? All benchmarks I could find point to a different picture than described in parent comment
.NET is far more widely used for desktop and web backends.
Taylor Swift is the most popular artist of all time. Is she also the best and your favorite?
Popularity is important, but it doesn't mean anything by itself.
I know that Rust/Zig was superior to all of these tools and in fact has smaller base
You don't need to sold me, I already use both of them
Hope you can migrate out of these legacy tech stack
[flagged]
[flagged]
Rust is a tool not for application development. It has a huge space in drivers, renderers and other low level places.
Node and Python are dynamically typed and at least originally scripting focused. They are not the right choice for many development active which are focused.
.NET plays with Go and Java in the same category of use cases. And there it boils down to devs you have.
Regards ecosystem: I am at home in both, .NET and JavaScript (browser more) and I can tell you: ecosystem is in 2025 no problem. Was back in the 2010s.
About the devs: you have what you have and hire along. Like Java, it will not go away. You get good ones and bad ones. Like for any other language.
Let us be less religious here. Objectively, .NET is like Go and Java a fit contender for its niche and selection goes along the lines what you have as workforce/systems already in place. In a startup situation you follow the preferences of your CTO.
I know where .NET fits: game development and legacy Windows apps. Otherwise, we don't need .NET—and let's not forget how HN feels when they have to deal with the MS tech stack.
Most .net projects are web API, and backend applications.
By a factor of 1000. Unreal.
"Most .net projects are web API, and backend applications."
if this year is 2015 then you are right
You have absolutely no clue what you're talking about, mate. .NET is like Java. It's behind critical systems you haven't heard of because they're not flashy or glamorous, so you have no idea how prevalent they actually are.
The other posters are right. Most .NET projects today are backends, where it's used similarly to how Java is used.
Bravo, such a well written article.
Feeling motivated enough to deep dive into .NET 10
I use c# also to earn my money. Sadly the new custom to hyperinflation in language sugar and framework makes following new things quite hard. Even today starting a new project I choose .net framework 3.5 and syntax. I know this sounds extreme but 3.5 has anything I need to build great software. It also offers a very tested environment. Setting up the software stack is a very easy process. Programmed following v2 runtime also work on v4 runtime so only a simple config file side by side to exe makes it run on any windows machine without any framework deployment.
.NET Framework 3.5 is so old it’s not available by default on Windows (maybe not available at all on the latest Windows), you’d probably have to work with ancient developer tooling to work with it, it’s probably unsupported and has security issues.
And that’s ignoring how you’re essentially severely handicapping yourself in terms of what is possible.
Unless you’re in an environment stuck 20 years in the past (which implies serious security liabilities considering they must be a Microsoft shop), this is a mind bogglingly bizarre strategy.
3.5 is approaching end of life in the next few years, you definitely should not building anything new with it. There's a lot of QoL changes in modern .NET that makes your life as a developer significantly nicer. Even for building windows services, the modern Generic Host model is orders of magnitude better than anything in .NET Framework.
I'm shocked that 3.5 is still supported, it came out in 2007!
I remember these days. But I have to say: .NET Core and .NET 5+ are awesome. They bring this ease you speak about into the cloud, into Linux, into containers. Obviously with the notable exception of UI development, but there the landscape has turned 5 times since 3.5 was released in 2007.
This is a strange take to me. I've been doing .NET for 25 years now. I don't see why you can't just write your code in "Framework 3.5" style in Visual Studio/VSCode 2026 with .NET 10? I would think almost any file from 3.5 would just drop in and compile with practically zero changes. I can't even think of any new language features that are being forced upon the developer.
Reminds me of an algorithms professor who'd get us to implement some modified standard algorithm in Java and then go over each implementation really quickly at the beginning of the next lecture. He'd find parts of your code weird, replace them really quickly and leave your clean, working implementation with 20 deprecation warnings.
At the end of the day both solutions/syntaxes work, but..