←back to thread

.NET 10

(devblogs.microsoft.com)
484 points runesoerensen | 1 comments | | HN request time: 0.206s | 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 #
parliament32 ◴[] No.45899481[source]
I think the key problem is that a large number of startups are shipping software in containers, and dotnet requiring a CLR is not particularly well-suited for containerization. It's like the old school Java JVM model. You have to ship a copy of the runtime with every container, and if you're doing proper microservices it's an awful lot of overhead.

Yes I'm aware MS makes it easy to build containers and even single executables, but languages that compile down to an ELF are pretty much a requirement once your deployments are over the 10k containers mark.

replies(11): >>45899527 #>>45900963 #>>45901005 #>>45901024 #>>45901026 #>>45901133 #>>45901711 #>>45901752 #>>45903133 #>>45904968 #>>45905736 #
1. stevefan1999 ◴[] No.45903133[source]
> dotnet requiring a CLR is not particularly well-suited for containerization

This is a solved problem within csproj to do dotnet publish to OCI containers already. I even have some csproj override to magically add it to every console projects in the solution.

The biggest problem IMO is because of the JIT generated code not being able to be saved, so it will always be regenerated on the fly, and compound that with a not so state-of-the-art GC (wish we have ZGC someday), it will create brief moment of latency very easily and making the timing fat-tailed.

NativeAOT and ReadyToRun remedies this problem by compiling ahead of time, but you trade space with time.