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!
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.
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.
EFCore by default is pretty performant - and pretty basic. You need to manually .Include() joins etc. which makes it pretty hard to become slow.
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!
At the end of the day both solutions/syntaxes work, but..
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.
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?
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.
.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.
The recently fixed the friction with odd number releases by providing 24 months of support.
The .Net platform is honestly the most stable it has ever been.
It's hard for me to imagine a version increment being much easier than this.
You should be able to go from .NET 6->10 without almost any changes at all.
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.
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.
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!
At least exactly due to performance issues, I get some excuses to push for C++ addons in some cases.
I cant see .net win againts those odds tbh
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.
This could also change but in my experience AI is better at generating Python code versus dotnet.
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.
.NET is certainly better than Python, but I'm not very happy with the type system and the code organization versus my Rust projects.
Horses for courses… also, a Horizontal Pod Autoscaler and Load Balancer setup is pretty cheap.
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.
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.
Why so many variants?
Then you've got the .NET SDK/aspnet/runtime (on x64/arm32/arm64 linux/mac/windows), and also the various SDK packages themselves.
Feeling motivated enough to deep dive into .NET 10