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

.NET 8 Standalone 50% Smaller On Linux

learn.microsoft.com

Post reply on HN
Print view View original

61–70 of 179 posts

Re: .NET 8 Standalone 50% Smaller On Linux

#61

Post by eddythompson80 »

slaymaker1907 wrote: post #44
unusualmonkey wrote: post #21

Earlier quoted context omitted.

I wouldn't be surprised if reflection usage starts diminishing, with source generators solving a number of use-cases while maintaining AOT.

I doubt it will reduce all that much. It’s still really convenient and it’s way more difficult to write and use a source generator than it is to just use reflection. Source generators will get used for stuff that really benefits from the extra safety and from the increased performance, but that still leaves many use cases for reflection.

I see most foundational libraries doing the effort to move to source generators everywhere possible. It's a big multiplier. Then it's up to the applications authors to choose if they care or not about AOT.

Re: .NET 8 Standalone 50% Smaller On Linux

#62

Post by skrebbel »

devjab wrote: post #47
skrebbel wrote: post #43

Earlier quoted context omitted.

> why would you pick C#? Because it’s a great language with amazing tooling. It’s fast, robust, easy to debug, easy to refactor, and so on. It’s also very easy to learn for novices and experienced programmers alike because it’s kind of the middle ground between many popular programming paradigms, and it has few surprising gotchas. It’s a fast way to get a heterogeneous team productive.

> Because it’s a great language with amazing tooling. It’s fast, robust, easy to debug, easy to refactor, and so on. I agree but I also think the main issue with this is that you could've said it in reference to most programming languages in 2023. I'm sure people can have a lot of debate on that, but aside from the fast bit, most programming languages are frankly in excellent places today, and fast is sort of irrelev…

I see your point and I agree. At the same time, our current backend is Elixir because the BEAM is a fantastic match to our product. It’s been the right choice but I miss C# every day. Never having typos, point and click debugging, renaming stuff in a second instead of 15 minutes of careful grepping, etc. I recognize eg the JVM has all this too but plenty other popular languages do not.

Re: .NET 8 Standalone 50% Smaller On Linux

#63

Post by vladvasiliu »

andrewstuart wrote: post #12

Who is using .NET on Linux? I'm interested to hear success stories. Sounds like a a great way to build and deploy applications.

Not me personally (I'm not a dev), but where I work, we have two teams working on two separate projects written in .net that run in Linux containers on ECS. The devs themselves use Visual Studio on Windows for local dev.

These things work very well and seem to use very few resources. Those systems manage retail kiosks and similar stuff, and one of the two systems is actually on the critical path for operation, so it's not like they only do housekeeping once in a while.

Re: .NET 8 Standalone 50% Smaller On Linux

#64

Post by majkinetor »

tentacleuno wrote: post #56
voxadam wrote: post #51

Earlier quoted context omitted.

I serve videos from my home Linux server using Jellyfin[0][1] and previously ran Emby[2] (from which Jellyfin was forked). Jellyfin is written in C# and runs on .NET 7. [0] https://jellyfin.org/ [1] https://github.com/jellyfin/jellyfin [2] https://emby.media/

Jellyfin is great for movies & shows. As an anecdote, it's not so good for music if you're a collector. I personally use Navidrome for that[0]. Anyway, Sonarr[1] makes use of .NET, too. Very reliable software, in my experience. [0]: https://github.com/navidrome/navidrome [1]: https://github.com/Sonarr/Sonarr

I am a music collector and I don't see a problem with Jelly, apart from android app pausing after first song.

It recognized my Musicbrainz filled library immediately without any problem, it was 0 effort to have it fully available on the web with multiple accounts.

Re: .NET 8 Standalone 50% Smaller On Linux

#65

Post by sshine »

devjab wrote: post #47
skrebbel wrote: post #43

Earlier quoted context omitted.

> why would you pick C#? Because it’s a great language with amazing tooling. It’s fast, robust, easy to debug, easy to refactor, and so on. It’s also very easy to learn for novices and experienced programmers alike because it’s kind of the middle ground between many popular programming paradigms, and it has few surprising gotchas. It’s a fast way to get a heterogeneous team productive.

> Because it’s a great language with amazing tooling. It’s fast, robust, easy to debug, easy to refactor, and so on. I agree but I also think the main issue with this is that you could've said it in reference to most programming languages in 2023. I'm sure people can have a lot of debate on that, but aside from the fast bit, most programming languages are frankly in excellent places today, and fast is sort of irrelev…

I was helping some friends with F# homework, and being a Rust programmer, I had to ask: your project file is XML, and the order you list the project files matter, and it won’t tell you that you listed them wrong?

Compile errors are super long lines and don’t show an excerpt of the code with underline under what went wrong with suggestions on how to fix it?

I know I’m asking a lot here, but that level is available with Rust and Elm.

Re: .NET 8 Standalone 50% Smaller On Linux

#67

Post by viraptor »

I've just tried to move an existing project to this and VS complained that the SDK doesn't support this version, even though I can create new projects with .net8. (preview SDKs are enabled) Is that some real limitation, or is VS being weird here?

There's https://marketplace.visualstudio.com/items?itemName=ms-dotne... out there, but I haven't tried it yet.

Re: .NET 8 Standalone 50% Smaller On Linux

#68

Post by pjmlp »

eddythompson80 wrote: post #59
pjmlp wrote: post #41

Earlier quoted context omitted.

Actually many people seem unaware that .NET has supported AOT since the beginning. The reason that they are unaware, mostly is that using NGEN requires really wanting to use it, as it requires dealing with strong named Assemblies, aka signed .NET libraries/executables. It only supports dynamic linking, and still pings back on the JIT for more complex code sequences, its original goal being fast startup time for deskt…

ngen had a lot of problems though. It was very easy to accidentally invalidate it. There was no easy reliable way to "ship" an ngen output. There was no easy way to even check if its even loading. your best option was to run ngen on the target machine, which is fine for services as a deployment step. But it's not like you could build and publish an AOT .NET cli for example.

Sure, as mentioned its key cases was fast startup for desktop applications.

The installation was supposed to take care of calling into ngen.

Re: .NET 8 Standalone 50% Smaller On Linux

#69

Post by pjc50 »

unusualmonkey wrote: post #21
fabian2k wrote: post #9

Earlier quoted context omitted.

.NET uses a lot of reflection, and you need to replace that with other mechanisms for AOT. And for modern .NET (previously named .NET Core, the version that also runs on Linux) you can package the runtime with the binary. You can even create single-file executables there, though those are still not AOT. The main advantage of AOT is startup time, and that didn't use to matter much for the kind of applications .NET was…

I wouldn't be surprised if reflection usage starts diminishing, with source generators solving a number of use-cases while maintaining AOT.

I'm about to embark on writing a source generator for XML serdes, because while the system XML one does support source gen, and always has, it has some annoying limitations (same element name must always map to the same class within the same assembly).

Re: .NET 8 Standalone 50% Smaller On Linux

#70

Post by supertron »

skrebbel wrote: post #28
devjab wrote: post #14

Earlier quoted context omitted.

We do, in the few things we haven’t yet migrated away from C#. I’m curious as to why you wouldn’t, it’s much cheaper than deploying on windows since you’ll likely need a license for that. We use it for a range of things. Mostly related to the legacy software of when our developers were mostly C# developers. Which isn’t how things are now, as C# has often stood in the way of our ability to deliver business value at a…

I agree that many of MS’s “open source” libraries (eg EF, OData) are half-assed, badly run projects. I’m also still mad at them for competing against amazing stuff like ServiceStack (a real OSS project from the community, and the best way to run REST APIs I’ve ever seen) with “official” but worse stuff like ASP.NET Web API. They do this a lot, some OSS gets popular but instead of embracing it, they make a half-assed…

> I agree that many of MS’s “open source” libraries (eg EF, OData) are half-assed, badly run projects.

Just as a counterpoint to this, I have found Entity Framework (Core) to be an extremely nice and very productive dev experience, with a lot of constant improvements in every release. MS don't always get it right, but I definitely wouldn't call EF a "half-assed, badly run project" by a long stretch. (Though there are probably other MS projects I might be more inclined to describe as such!)

That said, they were pretty brutal in cutting off legacy support for those still using .NET Framework and trying to migrate. Through luck, I didn't have to suffer too much pain, but the migration story from .NET Framework to the new world of .NET (including EF to EF Core) has not been the smoothest for some scenarios.

Post reply on HN