Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reinventing how .NET builds and ships (again)

devblogs.microsoft.com

Post reply on HN
Print view View original

31–40 of 146 posts

Re: Reinventing how .NET builds and ships (again)

#31

Post by mlhpdx »

UltraSane wrote: post #16
SamuelAdams wrote: post #5

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

That’s one reason I’ve preferred .Net. Put ahead of time compilation on top and it is glorious.

Re: Reinventing how .NET builds and ships (again)

#32

Post by acedTrex »

a1o wrote: post #30
chokolad wrote: post #7

Earlier quoted context omitted.

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

My guess is if you build with .NET Framework you can just forever run your builds, but if your source code is based on newer .NET you have to update to a new version each year, and deal with all the work in upgrading your entire project, which also means everyone in your team is also upgrading their dev environment, and now you have new things in the language and the runtime to deal with, deprecation and all that. Pl…

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

Re: Reinventing how .NET builds and ships (again)

#33

Post by WD-42 »

martinald wrote: post #13
SamuelAdams wrote: post #5

Earlier 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)…

Most web apps are waiting on the DB anyway. Rarely have I seen the speed of the actual framework make any meaningful difference.

Re: Reinventing how .NET builds and ships (again)

#34

Post by Krutonium »

a1o wrote: post #30
chokolad wrote: post #7

Earlier quoted context omitted.

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

My guess is if you build with .NET Framework you can just forever run your builds, but if your source code is based on newer .NET you have to update to a new version each year, and deal with all the work in upgrading your entire project, which also means everyone in your team is also upgrading their dev environment, and now you have new things in the language and the runtime to deal with, deprecation and all that. Pl…

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.

Re: Reinventing how .NET builds and ships (again)

#35

Post by gregmac »

a1o wrote: post #30
chokolad wrote: post #7

Earlier quoted context omitted.

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

My guess is if you build with .NET Framework you can just forever run your builds, but if your source code is based on newer .NET you have to update to a new version each year, and deal with all the work in upgrading your entire project, which also means everyone in your team is also upgrading their dev environment, and now you have new things in the language and the runtime to deal with, deprecation and all that. Pl…

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

Re: Reinventing how .NET builds and ships (again)

#36

Post by wolpoli »

gregmac wrote: post #35
a1o wrote: post #30

Earlier quoted context omitted.

My guess is if you build with .NET Framework you can just forever run your builds, but if your source code is based on newer .NET you have to update to a new version each year, and deal with all the work in upgrading your entire project, which also means everyone in your team is also upgrading their dev environment, and now you have new things in the language and the runtime to deal with, deprecation and all that. Pl…

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

> Odd numbers get 18 months of support/patches

The recently fixed the friction with odd number releases by providing 24 months of support.

Re: Reinventing how .NET builds and ships (again)

#37

Post by fijiaarone »

gregmac wrote: post #35
a1o wrote: post #30

Earlier quoted context omitted.

My guess is if you build with .NET Framework you can just forever run your builds, but if your source code is based on newer .NET you have to update to a new version each year, and deal with all the work in upgrading your entire project, which also means everyone in your team is also upgrading their dev environment, and now you have new things in the language and the runtime to deal with, deprecation and all that. Pl…

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

Ah, but if you use node.js you get breaking changes every other day from dependencies on dependencies you didn’t even know you had.

Re: Reinventing how .NET builds and ships (again)

#38

Post by arnonejoe »

N_Lens wrote: post #3

.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 C#. When combined with JetBrains Rider it may be the most satisfying dev experience I’ve had in my career.

Re: Reinventing how .NET builds and ships (again)

#39

Post by UltraSane »

zem wrote: post #23
UltraSane wrote: post #16

Earlier quoted context omitted.

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.

out of curiosity, why not kotlin? I had the impression it was the jvm language to reach for by default these days.

I'm dabbling and like it but there is just SO MUCH JAVA code. There are 1000 Java examples for every 1 Kotlin. Maybe LLMs make this less of an issue now though.

Re: Reinventing how .NET builds and ships (again)

#40

Post by UltraSane »

martinald wrote: post #20
UltraSane wrote: post #16

Earlier quoted context omitted.

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.

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…

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
Post reply on HN