←back to thread

.NET 10

(devblogs.microsoft.com)
484 points runesoerensen | 5 comments | | HN request time: 1.695s | 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 #
nicoburns ◴[] No.45900544[source]
> I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.

I tried .NET and liked C# as a language. But even though the language and runtime are now open source, it seemed like a lot of the recommended libraries were still commercially licensed, which was an immediate nope from me. I've never encountered that in any other ecosystem.

replies(12): >>45900964 #>>45901284 #>>45901414 #>>45903677 #>>45904049 #>>45904177 #>>45904488 #>>45907685 #>>45907873 #>>45908268 #>>45908319 #>>45908388 #
GiorgioG ◴[] No.45900964[source]
Recommended by whom? I've been doing .NET for 23 years (since the first beta) and I've never paid for a single library in any commercial project I've been part of.
replies(2): >>45901055 #>>45901101 #
whizzter ◴[] No.45901101[source]
Moq, lots of PDF libraries, Avalonia, Automapper, MediatR, MassTransit,Telerik stuff,etc.

I'm not inherently against it, we have a problem with opensource being asymmetrically underfunded and if people going commercial is the cost perhaps we've failed.

replies(5): >>45901189 #>>45901335 #>>45901358 #>>45901359 #>>45907465 #
1. majora2007 ◴[] No.45901189[source]
There are a few non-paid PDF libraries, but that is the biggest pain point in .NET, anytime you need advanced features for PDF, you're better off paying for a license (it's just insanely expensive unless you're a large company).

Having worked on some basic parsing of metadata from PDF spec, I would rather pay than have to code something myself. PDF is such a PIA.

replies(1): >>45901616 #
2. jasomill ◴[] No.45901616[source]
I've used libqpdf extensively from C++/CLI with excellent results, but since C++/CLI is deprecated-ish and Windows-only, I wouldn't disagree with PDF being a pain point, and if I get the time, a cross-platform open source .NET wrapper for libqpdf is at the top of my list of potential projects.

libqpdf also intentionally limits its scope to PDF structure, so doesn't address nontrivial content creation or manipulation (page content handling is pretty much limited to compressing/decompressing and parsing/unparsing the content stream).

replies(1): >>45904605 #
3. tracker1 ◴[] No.45904605[source]
AFAIK pinvoke (DllImport) works today just like it always has if you want to create FFI calls to C libraries. It's not windows only for sure.
replies(1): >>45906675 #
4. whizzter ◴[] No.45906675{3}[source]
That brings you back to managing memory though, C++/CLI having access to managed C# handles/references for GC'd objects (and finalization) would greatly simplify any memory management at the same time as having first class access to native libaries.

Granted, one could probably build some of the machinery memory management in a simple way but it'd still need to be done and probably not be coherent with other native interfaces.

replies(1): >>45907154 #
5. to11mtm ◴[] No.45907154{4}[source]
IDK, for certain cases those fancy libraries are just handling the ugly marshal calls for you.

Wayyyy back in the day, before package managers were a thing, I had to write something to output a PDF via DLL calls and frankly it wasn't a bad experience. Possibly outside of what is in a 'modern' workflow but honestly wasn't too difficult. Just wrap it all in a class that only gives what you need and avoids potential footguns via validation.

Frankly it was easier than doing anything with Autocad's 'managed' libraries [0].

Maybe it's rose colored glasses for me, but .NET had fairly simple rules for most marshal bits so long as you knew them, although I will admit we didn't worry about 'performance' for the stuff I wrote and that can be a factor.

[0] - Microstation had a bunch of fancy COM hooks and exposed all of it to .NET in a nice way. AutoCAD 'managed' libs had all sorts of weird sorts of arcane rules and if you failed to follow them not only could you crash your .NET process but Autocad could remain unstable until you rebooted the PC... which is why I keep putting managed in air quotes.