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

Understanding the .NET ecosystem: The evolution of .NET into .NET 7

andrewlock.net

Post reply on HN
Print view View original

291–300 of 357 posts

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#291

Post by Guillaume86 »

skeletonjelly wrote: post #221
Guillaume86 wrote: post #169

Earlier quoted context omitted.

> Right now EF Core is probably the best ORM that has ever existed. What exactly is missing? Wish I could agree but they would have to fix the very slow time to first query when using big models (+500 tables in our case). Compiled models is not a solution for us since our model changes a lot and the compilation is just as slow. It's disappointing because it used to work fine under the ancient Linq2SQL library.

Can't you generate the compiled model as part of the CI/CD? Also maybe you might find a benefit from splitting your context into multiples. I am considering this option for one of my code bases

I can but the DX would still be miserable, starting a local instance would still incur the cost of building the model, and a dev need to do that a lot of times during a day.

I can't split the model without massive refactorings, and even then, some tables are common across all modules and would need to be duplicated. Your advice is unfortunately the standard answer in my case, I guess EF Core is just not for me, really disappointing but "c'est la vie".

edit: ha you probably mean commit it in source control so other devs can also use it? I guess it's a compromise, would still slow down our DbContext refresh command a lot.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#292

Post by pjmlp »

Nullabillity wrote: post #288
pjmlp wrote: post #273

Earlier quoted context omitted.

The competitor doesn't ship a full OS SDK for all kinds of development. Go see how much GB, Apple or Android development stacks require.

$ pacman -Qi emacs | grep Size Installed Size : 111,46 MiB

I guess if anything you is Emacs Lisp, targeting the Emacs OS, then ok.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#293

Post by _piif »

zip1234 wrote: post #64
nonethewiser wrote: post #31

Earlier quoted context omitted.

It better be at a 30GB install size.

A 2TB nvme drive is less than $200. If VS is saving significant dev time, people would install it even if much larger install.

Also transparent compression is a thing in case you need to squeeze out more space. And I don't mean the shoddy NTFS active compression. It received support for much more efficient compression algorithms since win10 which are accessible using compact.exe[0], albeit passive rather than active so there is decay once files get modified.

[0] https://learn.microsoft.com/en-us/windows-server/administrat...

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#294

Post by paddim8 »

ThorsBane wrote: post #213
brushfoot wrote: post #33

.NET has been doing a lot of things right. My startup's codebase is nearly all .NET 7: landing page, web app, Windows service, API. The main non-.NET code is vanilla JS in the web app. I've been keeping a close eye on Next.js, which is very well done, but I love how versatile .NET is. With one language, I can write all of the above, and my dependencies are minimal thanks to .NET's rich standard library - a refreshing…

How do the costs of running the .NET 7 codebase compare with running something open? I like .NET a lot, have worked with it a lot in the past. But when I tried my own startup, I picked node instead and don't really regret it. I'm getting back into .NET these days though at a new job again, and .NET 7 will be interesting to dive into. Still not sure I'd want to be that tightly-coupled to Microsoft subscriptions though…

What do you mean open? It is open

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#295

Post by Loocid »

pjmlp wrote: post #280
Loocid wrote: post #137

Earlier quoted context omitted.

I strongly recommend Rider, even for those using Windows. It's a great piece of software.

Why pay for half of the experience of IDE from the OS vendor, specially when having MSDN licenses already paid for?

What half is Rider missing? And of course you should use VS if you're getting it for free while having to pay for Rider.

I find Rider a much more smooth experience than VS. It's faster in almost every way (loading solutions, searching, etc).

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#296

Post by miffy900 »

ThorsBane wrote: post #213
brushfoot wrote: post #33

.NET has been doing a lot of things right. My startup's codebase is nearly all .NET 7: landing page, web app, Windows service, API. The main non-.NET code is vanilla JS in the web app. I've been keeping a close eye on Next.js, which is very well done, but I love how versatile .NET is. With one language, I can write all of the above, and my dependencies are minimal thanks to .NET's rich standard library - a refreshing…

How do the costs of running the .NET 7 codebase compare with running something open? I like .NET a lot, have worked with it a lot in the past. But when I tried my own startup, I picked node instead and don't really regret it. I'm getting back into .NET these days though at a new job again, and .NET 7 will be interesting to dive into. Still not sure I'd want to be that tightly-coupled to Microsoft subscriptions though…

> How do the costs of running the .NET 7 codebase compare with running something open?

.NET has been open source since .NET Core 1 in 2017. The source code is on GitHub: https://github.com/dotnet/

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#297

Post by Kwpolska »

osigurdson wrote: post #179
Kwpolska wrote: post #107

Earlier quoted context omitted.

The issue is with Googling (or Binging if you’re so inclined). If you google ".NET foobar", you might get answers for .NET Core, but you might also get old answers for the .NET Framework, written at a time when there was just one .NET, or when .NET Core was not as relevant and not the “real” .NET. Of course, it’s not super important if “foobar” is something simple and generic, like “.NET split string”, but when you g…

Suggest using ChatGPT instead of google.

Then go ahead and ask it, and tell us the results. A good query would be “How are assemblies loaded in .NET?”, and if the response talks about the Global Assembly Cache (GAC), app.config, or assembly redirections, it’s not applicable to the modern .NET.

I’m skeptical, ChatGPT is not magic, and it was trained on ~15 years’ worth of “there is only one .NET Framework, so we might as well call it .NET” content, ~5 years of “.NET Framework is for serious business, and there’s the cross-platform (mostly-)web .NET Core” content, and 1 year of “.NET 5 is the future of .NET”.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#298

Post by shreyasonline »

Kwpolska wrote: post #88
jiggawatts wrote: post #62

My big problem with .NET is that a lot of line-of-business apps were written using ASP.NET Web Forms, but there is no upgrade path other than “rewrite most of it”. It feels like the pain everyone went through upgrading from Python 2 to Python 3. It also doesn’t help that .NET Framework has its support cycle tied to the OS, and hence is 10+ years. This means that businesses can be lazy and just leave these old apps to…

ASP.NET Web Forms are a complete trainwreck and an abuse of HTTP and other basic web development standards (e.g. by using javascript: URLs and POSTing forms for every single interaction with the page). It is broken by design. ASP.NET MVC 1.0 came out in 2009, there was plenty of time to modernize those apps.

It seems you have not kept up with .NET development. Web Forms have been obsolete since many years by now.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#299

Post by andix »

Someone1234 wrote: post #192
andix wrote: post #133

Earlier quoted context omitted.

Technologies don’t live forever. At some point you need to upgrade, and at some points there will be some major breaking changes. .NET 4.8 is still fully supported, and there is no end-of-life communicated yet. It is a part of windows server 2022, which will be supported until 2031, that’s probably the earliest possible end-of-life date for .NET 4.8.

If people are looking at what technologies and companies to invest in, knowing that they may be left high and dry with a "full rewrite"-level of breaking changes is a valid and relevant critique. You want to know you'll be supported through difficult transitions, and that isn't unreasonable. I don't understand why people are coming out of the woodwork to tell everyone that full rewrites are a perfectly normal and exp…

Do you have any example what technology gave you a clean upgrade path from 2005 until now, without the need to do major changes?

With .NET you can still, use most of your code from 2001, just the UI frameworks (and WCF) are not supported anymore on .NET 5+. They are supported at least until 2031 on .NET 4.8. So you can easily move your business logic to a newer version and leave the UI on an older version. But seriously, who is still happy with a web application built in 2005?

Post reply on HN