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

121–130 of 146 posts

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

#121

Post by tracker1 »

mynameisash wrote: post #26
martinald wrote: post #13

Earlier quoted context omitted.

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

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

Take a look at FastEndpoints library for API development... definitely improves the experience a lot IMO...

That said, Rust+Axum is pretty nice as well.

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

#122

Post by whoknowsidont »

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.

>.NET was a solid choice for backend builds before Node became so popular

The problem with the community is that this statement has been said for every version in every era despite how untrue it is lol. No matter what ills or blights .NET will put on your solution the developers will always sing its real or imagined praises.

This is the #1 reason I avoid interacting and working with .NET teams because it's still true to this day.

Honesty would go a long way.

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

#123

Post by whoknowsidont »

oaiey wrote: post #64
neonsunset wrote: post #50

Earlier quoted context omitted.

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

Or users of other programming tool chains.

AKA people who are willing to be honest about its faults. .NET has a lot of social commentary on how stable and robust it is yet for some reason in every project I've had the displeasure of brushing up against a .NET solution it's always "we're updating" and the update process magically takes longer than building the actual feature.

Or what is a pretty standard feature in other tech-stacks needs some bespoke solution that takes 3 dev cycles to implement... and of course there's going to be bugs.

And it's ALWAYS been this way. For some reason .NET has acolytes who have _always_ viewed .NET has the pinnacle of programming frameworks. .NET, Core, .NET framework, it doesn't matter.

You always get the same comments. For decades at the point.

Except the experience and outcomes don't match the claims.

Just before I get the reply, I'm pretty familiar with .NET since the 2000's.

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

#124

Post by vjvjvjvjghv »

littlecranky67 wrote: post #87
vjvjvjvjghv wrote: post #47

Earlier quoted context omitted.

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.

Are you talking about EF or EF Core? If the later, did you enable any or all of the magic like automatic property evaluation/eager fetching etc.? EFCore by default is pretty performant - and pretty basic. You need to manually .Include() joins etc. which makes it pretty hard to become slow.

EF Core. It’s fine to some degree but larger queries with lots of joins can get very slow. Not all but just some of them.

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

#125

Post by orphea »

pjmlp wrote: post #97
orphea wrote: post #92

Earlier quoted context omitted.

You're describing a specific case of working in a big rigid enterprise. It doesn't have anything to do with .NET itself, does it?

Guess where most .NET developers employeers happen to be?

I have no idea about most .NET developers. At my current job (a public software company in US with thousands of employees) it's up to engineers to decide when to upgrade. We upgraded our main monolith app to .NET 10 in the first week.

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

#126

Post by mynameisash »

sasmithjr wrote: post #102
mynameisash wrote: post #26

Earlier quoted context omitted.

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

> .NET is certainly better than Python, but I'm not very happy with the type system and the code organization versus my Rust projects. Have you given F# a whirl?

You know, I tried F# like eight-ish years ago, and I loved it, but I couldn't break into doing it with enough regularity and depth that it made sense for me. I still do a decent amount of C# at work, and with my experience in Rust (algebraic data types, etc.), I imagine that F# would really help out a lot in our .NET code.

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

#127

Post by cm2187 »

algorithmsRcool wrote: post #101
cm2187 wrote: post #84

Earlier quoted context omitted.

I am not sure what the stats are but I am certain they left behind a huge number of projects. Probably a population that won't be very vocal on HN but that doesn't mean they don't exist. Even for new projects there are problems I run into that force me to use 4.8. Like if you build an Excel formula, the mandatory async/await approach just doesn't work. It's not an asynchronous operation and runs into a UI context whe…

> Like if you build an Excel formula, the mandatory async/await approach just doesn't work. It's not an asynchronous operation and runs into a UI context where you deadlock if you wait. Last time I did excel interop it was COM based and there wasn't any async part of it. I'm curious if you were using COM interop also? Also, async/await was explicitly designed to work in UI contexts like Winforms and WPF where there i…

For writing excel formulas, while I think you can use VSTO/COM, you will get a poor performance if you do. The "right" way to do it is with ExcelDNA/ManagedXLL. But the excel calculation engine was never designed to support async/await, and your calculations operate within a UI thread. So if you need to make a network call in one of your excel functions, you quickly run out of options.

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

#128

Post by debugnik »

lbussell wrote: post #110
debugnik wrote: post #104

Earlier quoted context omitted.

I glad to read this. One of my long-term concerns with .NET, compared to other language ecosystems, is the risk that only Microsoft people might know how to build it and port it. Is any distro actually shipping .NET SDK packages built from source?

Yes - Ubuntu, Alpine, Fedora, and others. [1] [1]: https://github.com/dotnet/source-build/blob/main/README.md#n...

Thanks for the reference. I had memories of having to install a Microsoft repository to install the SDK, that's an improvement.

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

#129

Post by debugnik »

mmitche-msft wrote: post #117
debugnik wrote: post #104

Earlier quoted context omitted.

I glad to read this. One of my long-term concerns with .NET, compared to other language ecosystems, is the risk that only Microsoft people might know how to build it and port it. Is any distro actually shipping .NET SDK packages built from source?

Yes, Canonical, RedHat, Fedora, Alpine, Centos, and Arch Linux. NixOS and nixpackages too.

Looks like I missed progress during the time I've been away from dotnet, thanks. I still had memories of having to install an MS repo for that.

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

#130

Post by pjmlp »

tracker1 wrote: post #115
pjmlp wrote: post #73

Earlier quoted context omitted.

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.

On the migrations... read the comments through this thread.. there are many, and none have mentioned any significant pain points at all, just hypothetical ones from people like you who aren't actually actively using it. As to the CI/CD pipelines... I just edited my .github/workflow/* to bump the target version, and off to the races... though if you're deploying to bare metal as opposed to containers, it does take a c…

Each one is their own anecdote.
Post reply on HN