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

The past three years of dotnet upgrades have been completely painless for me.

Note how practitioners of .NET praise it and non-practitioners (users of .NET Framework) criticize it.

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.

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!

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.

It has the benefit of being late to the game (like .NET was to Java).

Why don't people use subtree?

https://www.atlassian.com/git/tutorials/git-subtree

numbers speak for themselves

downvoted for saying truth

who tf needs .Net when there are Go, Node(bun), Rust/Zig etc

1. Net is not faster than (Rust, Zig)

2. ecosystem is smaller (Node,Python)

3. less developer experience (Go,Node)

there is no need to fill up the gap

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

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.

Just make them internal and use [InternalsVisibleTo] on the assembly.

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.

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.