3 ms·

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

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.

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.