←back to thread

.NET 10

(devblogs.microsoft.com)
489 points runesoerensen | 2 comments | | HN request time: 0.666s | source
Show context
jitbit ◴[] No.45888669[source]
For us, every .NET upgrade since .NET 5 has gone surprisingly smoothly and reduced CPU/RAM usage by 10–15%.

We were even able to downgrade our cloud servers to smaller instances, literally.

I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.

replies(26): >>45888799 #>>45888804 #>>45889332 #>>45891939 #>>45896032 #>>45898279 #>>45898305 #>>45898358 #>>45898503 #>>45898877 #>>45899062 #>>45899235 #>>45899246 #>>45899326 #>>45899445 #>>45899481 #>>45899858 #>>45900544 #>>45900791 #>>45900829 #>>45903218 #>>45904345 #>>45904435 #>>45905041 #>>45906073 #>>45907122 #
vintagedave ◴[] No.45891939[source]
.Net is also good as a platform for other languages. I recently started working with RemObjects, and you can compile languages like Java, Swift, Go and more (VB, Pascal) to .Net. Then, the whole framework and ecosystem is available. I'm liking it a lot.

They have customers who are startups and the 'got to have tools' folk like having lots of languages since they can onboard people who know anything-not-C# and benefit from the .Net library.

replies(1): >>45898267 #
sfn42 ◴[] No.45898267[source]
> they can onboard people who know anything-not-C# and benefit from the .Net library

I don't get this mindset. I'd much rather have the new guy spend a few months getting used to a new language, than have an organization where everyone uses different languages. It's a nightmare a few years down the road when you have 20 different projects in 15 different languages and the people who built them are mostly gone.

People are way too lenient with this stuff IMO. The goal of an organization should be to have one solution to each problem. For example we use .NET for backend and React for frontend. You don't need anything else. People love to talk about the right tool for the job, it's all BS. You can make pretty much any kind of website using react and pretty much any kind of backend using C#. The only reason to choose anything else is preference.

And sure maybe you have some data science people who need python, thats fine. Just don't have one guy using Py, another using R and yet others using Matlab. That's just asking for trouble. Pick one, stick to it. If you're going to make a change then migrate everything. If it's not worth that then the new tool probably isn't such a big deal after all.

replies(5): >>45898705 #>>45898855 #>>45898990 #>>45899707 #>>45900509 #
Razengan ◴[] No.45898855[source]
Do you also make everyone wear the same clothes, drive the same vehicle, order the same food
replies(2): >>45898889 #>>45899291 #
SideburnsOfDoom ◴[] No.45898889[source]
> Do you also make everyone drive the same vehicle

Good analogy. If, say, your organisation maintains a fleet of cars - it needs to keep them on the road, get them serviced, replace parts, refresh individual cars regularly etc.

How many different makes and models do you support? A small org might decide that it only makes sense to support one. A larger org might have the resources for 3 or 4, so that there is 1 or 2 "general purpose" models, and then other ones suited to specialised tasks.

replies(1): >>45899086 #
Razengan ◴[] No.45899086[source]
But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..
replies(4): >>45899147 #>>45899347 #>>45899483 #>>45902989 #
SideburnsOfDoom ◴[] No.45899483[source]
I think that question is more "how many different makes of van can your delivery company afford to maintain?"

Which is an analogy for "how many different programming languages for the same task of serving a web api can you company afford to support?"

The majority of programming languages (c# definitely included!) are "general purpose", i.e. they can be used well enough for almost all tasks. They're not so different as a truck vs. a bicycle.

The issue is not so much "we need firmware in Rust and statistical analysis in R" - that's fair! The issue is more, as others have said, web apps or similar in multiple equivalent languages. This is an overhead. If you take on that overhead, recognise that 1) it has definite drawbacks and 2) for mundane tasks, the advantages aren't large. and 3) chances are your organisation is like most orgs - you don't do all of firmware, statistical analysis and web apps, in house.

replies(1): >>45900681 #
1. skeeter2020 ◴[] No.45900681[source]
Car models get maybe refreshed annually, bigger changes a couple of times a decade, if that. Vehicle fleets are often aging out with these timelines.

So if we either stretch the fleet management analogy to 50 years, or software applications only lasted 3-5 years maybe it IS fair to say the both have either a lot (former) or very little (later) inconsistnency?

replies(1): >>45900915 #
2. SideburnsOfDoom ◴[] No.45900915[source]
> Car models get maybe refreshed annually, bigger changes a couple of times a decade, if that.

.NET gets refreshed annually. The last bigger change was nearly a decade ago. So not all that different.

But I don't think that the analogy stretches, really. e.g. where I am all .NET apps are .NET 8 LTS or 9, and will be all be .NET 10 LTS by middle of 2026. You can upgrade an app to a new model year much more easily than a vehicle. The "software application, on a SDK major version" only lasts 1-2 years.