6 ms·

.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

by N_Lens 11mo ago

.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.

SamuelAdams 11mo ago
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.
- martinald 11mo ago
  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.
  - casper14 11mo ago
    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
    - array_key_first 11mo ago
      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.
  - mynameisash 11mo 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.
    - sasmithjr 11mo ago
      > .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?
      - mynameisash 11mo ago
        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.
    - tracker1 11mo ago
      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.
  - WD-42 11mo ago
    Most web apps are waiting on the DB anyway. Rarely have I seen the speed of the actual framework make any meaningful difference.
  - jtbaker 11mo ago
    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.
- UltraSane 11mo ago
  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.
  - martinald 11mo ago
    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.
    - UltraSane 11mo ago
      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
    - fijiaarone 11mo ago
      On most cloud deployments, you get one shared “virtual” core — whatever that means.
      - UltraSane 11mo ago
        No you get how ever many you choose and are willing to pay for. 1vCPU is not good for very much.
  - zem 11mo ago
    out of curiosity, why not kotlin? I had the impression it was the jvm language to reach for by default these days.
- sanex 11mo ago
  If you don't want your methods to be private make them public?
  - carry_bit 11mo ago
    Just make them internal and use [InternalsVisibleTo] on the assembly.
chokolad 11mo ago
> 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?
- da_chicken 11mo ago
  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.
  - Rohansi 11mo ago
    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.
    - pjmlp 11mo ago
      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.
      - lan321 11mo ago
martinald 11mo ago
This isn't really anything user facing. It's just yet again an example of why monorepos are better.
- jerezzprime 11mo ago
  Anything is a monorepo if you submodule hard enough lol
  - mcny 11mo ago
    Why don't people use subtree? https://www.atlassian.com/git/tutorials/git-subtree https://www.atlassian.com/git/tutorials/git-subtree
    - Smaug123 11mo ago
      The .NET source build team looked at subtrees (https://github.com/dotnet/arcade/issues/10257#issuecomment-1205090811 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/766c564dd379e634c3873943174530be3181e7b2%5E/docs/VMR-Design-And-Operation.md#repository-source-mappings https://github.com/premun/dotnet/blob/766c564dd379e634c38739... )
tonyhart7 11mo ago
.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
- smt88 11mo ago
  .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
  - tonyhart7 11mo ago
    numbers speak for themselves
    - zihotki 11mo ago
      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
    - oaiey 11mo ago
      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.
      - array_key_first 11mo ago
        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.
    - smt88 11mo ago
      .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.
anonymous908213 11mo ago
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.
- frank_nitti 11mo ago
  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
  - jve 11mo ago
arnonejoe 11mo ago
I love C#. When combined with JetBrains Rider it may be the most satisfying dev experience I’ve had in my career.
croes 11mo ago
Is nuget any different from npm
- stuartd 11mo ago
  It is, shall we say, more curated
  - oaiey 11mo ago
    It has the benefit of being late to the game (like .NET was to Java).
smt88 11mo ago
.NET churns less than any other major stack. Every upgrade since Core 2 (released in 2017) has been minimally painful or, more recently, painless.
- tracker1 11mo ago
  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.
pjmlp 11mo ago
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.
tracker1 11mo ago
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.
whoknowsidont 11mo ago
>.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.

by N_Lens 11mo ago

SamuelAdams 11mo ago

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.

martinald 11mo ago
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.
- casper14 11mo ago
  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
  - array_key_first 11mo ago
    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.
- mynameisash 11mo 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.
  - sasmithjr 11mo ago
    > .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?
    - mynameisash 11mo ago
      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.
  - tracker1 11mo ago
    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.
- WD-42 11mo ago
  Most web apps are waiting on the DB anyway. Rarely have I seen the speed of the actual framework make any meaningful difference.
- jtbaker 11mo ago
  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.
UltraSane 11mo ago
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.
- martinald 11mo ago
  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.
  - UltraSane 11mo ago
    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
  - fijiaarone 11mo ago
    On most cloud deployments, you get one shared “virtual” core — whatever that means.
    - UltraSane 11mo ago
      No you get how ever many you choose and are willing to pay for. 1vCPU is not good for very much.
- zem 11mo ago
  out of curiosity, why not kotlin? I had the impression it was the jvm language to reach for by default these days.
sanex 11mo ago
If you don't want your methods to be private make them public?
- carry_bit 11mo ago
  Just make them internal and use [InternalsVisibleTo] on the assembly.

chokolad 11mo ago

> 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?

da_chicken 11mo ago
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.
- Rohansi 11mo ago
  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.
  - pjmlp 11mo ago
    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.
    - lan321 11mo ago

martinald 11mo ago

This isn't really anything user facing. It's just yet again an example of why monorepos are better.

jerezzprime 11mo ago
Anything is a monorepo if you submodule hard enough lol
- mcny 11mo ago
  Why don't people use subtree? https://www.atlassian.com/git/tutorials/git-subtree https://www.atlassian.com/git/tutorials/git-subtree
  - Smaug123 11mo ago
    The .NET source build team looked at subtrees (https://github.com/dotnet/arcade/issues/10257#issuecomment-1205090811 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/766c564dd379e634c3873943174530be3181e7b2%5E/docs/VMR-Design-And-Operation.md#repository-source-mappings https://github.com/premun/dotnet/blob/766c564dd379e634c38739... )

tonyhart7 11mo ago

.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

smt88 11mo ago
.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
- tonyhart7 11mo ago
  numbers speak for themselves
  - zihotki 11mo ago
    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
  - oaiey 11mo ago
    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.
    - array_key_first 11mo ago
      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.
  - smt88 11mo ago
    .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.

anonymous908213 11mo ago

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.

frank_nitti 11mo ago
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
- jve 11mo ago

arnonejoe 11mo ago

I love C#. When combined with JetBrains Rider it may be the most satisfying dev experience I’ve had in my career.

croes 11mo ago

Is nuget any different from npm

stuartd 11mo ago
It is, shall we say, more curated
- oaiey 11mo ago
  It has the benefit of being late to the game (like .NET was to Java).

smt88 11mo ago

.NET churns less than any other major stack. Every upgrade since Core 2 (released in 2017) has been minimally painful or, more recently, painless.

tracker1 11mo ago
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.

pjmlp 11mo ago

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.

tracker1 11mo ago

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.

whoknowsidont 11mo ago

>.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.