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

71–80 of 146 posts

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

#71

Post by pjmlp »

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

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

#72

Post by zihotki »

tonyhart7 wrote: post #57
smt88 wrote: post #51

Earlier quoted context omitted.

.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

numbers speak for themselves

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

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

#73

Post by pjmlp »

Rohansi wrote: post #49
da_chicken wrote: post #29

Earlier quoted context omitted.

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…

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.

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.

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

#74

Post by zem »

oaiey wrote: post #63
zem wrote: post #21

one thing that struck me was that the foundation for this effort was the linux distro build system. in other words, the work they put into making .net open-source and cross-platform eventually made everyone's lives easier.

I think .NET is way beyond the situation that they question their open source move. The amount of pull requests and positive outcomes for them in the last 10 years (yeah that long already) is mind blowing.

yeah, I didn't mean that it was evidence the open source move was successful or valuable, more that it showed that the engineering effort that went into the open sourcing also yielded dividends for the project in general

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

#75

Post by jonathanlydall »

Surac wrote: post #61

I use c# also to earn my money. Sadly the new custom to hyperinflation in language sugar and framework makes following new things quite hard. Even today starting a new project I choose .net framework 3.5 and syntax. I know this sounds extreme but 3.5 has anything I need to build great software. It also offers a very tested environment. Setting up the software stack is a very easy process. Programmed following v2 runt…

.NET Framework 3.5 is so old it’s not available by default on Windows (maybe not available at all on the latest Windows), you’d probably have to work with ancient developer tooling to work with it, it’s probably unsupported and has security issues.

And that’s ignoring how you’re essentially severely handicapping yourself in terms of what is possible.

Unless you’re in an environment stuck 20 years in the past (which implies serious security liabilities considering they must be a Microsoft shop), this is a mind bogglingly bizarre strategy.

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

#76

Post by oaiey »

tonyhart7 wrote: post #57
smt88 wrote: post #51

Earlier quoted context omitted.

.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

numbers speak for themselves

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.

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

#77

Post by oaiey »

tonyhart7 wrote: post #56
smashedtoatoms wrote: post #55

Earlier quoted context omitted.

[flagged]

[flagged]

Rust is a tool not for application development. It has a huge space in drivers, renderers and other low level places.

Node and Python are dynamically typed and at least originally scripting focused. They are not the right choice for many development active which are focused.

.NET plays with Go and Java in the same category of use cases. And there it boils down to devs you have.

Regards ecosystem: I am at home in both, .NET and JavaScript (browser more) and I can tell you: ecosystem is in 2025 no problem. Was back in the 2010s.

About the devs: you have what you have and hire along. Like Java, it will not go away. You get good ones and bad ones. Like for any other language.

Let us be less religious here. Objectively, .NET is like Go and Java a fit contender for its niche and selection goes along the lines what you have as workforce/systems already in place. In a startup situation you follow the preferences of your CTO.

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

#78

Post by oaiey »

vjvjvjvjghv wrote: post #47
yndoendo wrote: post #44

Earlier quoted context omitted.

Last time I tried Entity Framework it was slow. Replaced it with Dapper and a simple custom migration system. This took database validation and seeding from 10 seconds to less than 2 seconds during startup on low powered hardware with SQLite. The queries created by Entity had pointless cascade of multiple join statements. I have been reaching for GO with simple tooling and HTTP back end. .NET is useful for other solu…

We are also running into more and more performance issues with EF. There are ways to tune it but I am not sure if it’s worth learning this for EF or if it’s not better to just go for straight SQL. Seems MS has this tendency to create abstractions that then don’t work 100%. I see this with .NET too. Often you have to go down to Win32 for apps that are tightly coupled with Windows and hardware.

Is not that the core problem with ORMs. All of them. In the end you do straight SQL when it comes to Performance.

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

#79

Post by qingcharles »

yndoendo wrote: post #44
hu3 wrote: post #18

I have a lot of respect for the .NET team. They often publish great in-depth articles and their pursuit for performance is relentless (e.g. see Kestrel and Entity Framework evolution). And 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 t…

Last time I tried Entity Framework it was slow. Replaced it with Dapper and a simple custom migration system. This took database validation and seeding from 10 seconds to less than 2 seconds during startup on low powered hardware with SQLite. The queries created by Entity had pointless cascade of multiple join statements. I have been reaching for GO with simple tooling and HTTP back end. .NET is useful for other solu…

I just went the other way and tore all my Dapper + SQL and repositories out of a big project and switched it all to EF Core 10. Not noticed any change in performance but dumped thousands of lines of unnecessary code. I like the tighter code, but you definitely do need to keep your eye on the "magic" of EF to avoid it doing anything goofy that isn't easily visible.

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

#80

Post by qingcharles »

Surac wrote: post #61

I use c# also to earn my money. Sadly the new custom to hyperinflation in language sugar and framework makes following new things quite hard. Even today starting a new project I choose .net framework 3.5 and syntax. I know this sounds extreme but 3.5 has anything I need to build great software. It also offers a very tested environment. Setting up the software stack is a very easy process. Programmed following v2 runt…

This is a strange take to me. I've been doing .NET for 25 years now. I don't see why you can't just write your code in "Framework 3.5" style in Visual Studio/VSCode 2026 with .NET 10? I would think almost any file from 3.5 would just drop in and compile with practically zero changes. I can't even think of any new language features that are being forced upon the developer.
Post reply on HN