Live data from Hacker News

Reinventing how .NET builds and ships (again)

devblogs.microsoft.com

51–60 of 146 posts

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

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

.Net need a "node" level of developer experience and perfomance of rust/zig since node/python ecosystem rewrite make it more perfomance than ever I cant see .net win againts those odds tbh

.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

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

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

.NET churns less than any other major stack. Every upgrade since Core 2 (released in 2017) has been minimally painful or, more recently, painless.

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

#53

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.

[dead]

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

#54
post #30
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…

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.

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

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

.Net need a "node" level of developer experience and perfomance of rust/zig since node/python ecosystem rewrite make it more perfomance than ever I cant see .net win againts those odds tbh

[flagged]

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

#56

Earlier quoted context omitted.

.Net need a "node" level of developer experience and perfomance of rust/zig since node/python ecosystem rewrite make it more perfomance than ever I cant see .net win againts those odds tbh

[flagged]

[flagged]

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

#57
post #51

Earlier quoted context omitted.

.Net need a "node" level of developer experience and perfomance of rust/zig since node/python ecosystem rewrite make it more perfomance than ever I cant see .net win againts those odds tbh

.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

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

#58

Earlier quoted context omitted.

This isn't really anything user facing. It's just yet again an example of why monorepos are better.

Anything is a monorepo if you submodule hard enough lol

Why don't people use subtree?

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

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

#59
post #48
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.

Is nuget any different from npm

It is, shall we say, more curated

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

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

ef core is great for simple queries and modification of your data while using the changetracker. You can use AsNoTracking/Projection to perform similar like dapper for queries. When using command query seperation you can also use dapper for queries and ef core for commands.
Post reply on HN