> 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.
Reinventing how .NET builds and ships (again)
11–20 of 146 posts
Re: Reinventing how .NET builds and ships (again)
#12.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.
This isn't really anything user facing. It's just yet again an example of why monorepos are better.
Re: Reinventing how .NET builds and ships (again)
#13.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 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.
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.
Re: Reinventing how .NET builds and ships (again)
#14.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.
Re: Reinventing how .NET builds and ships (again)
#15Earlier quoted context omitted.
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?
Re: Reinventing how .NET builds and ships (again)
#16.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 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.
Re: Reinventing how .NET builds and ships (again)
#17Earlier quoted context omitted.
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)…
Re: Reinventing how .NET builds and ships (again)
#18And 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!
Re: Reinventing how .NET builds and ships (again)
#19.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 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.
Re: Reinventing how .NET builds and ships (again)
#20Earlier quoted context omitted.
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.
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.
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.