Live data from Hacker News

.NET 8 Standalone 50% Smaller On Linux

learn.microsoft.com

41–50 of 179 posts

Re: .NET 8 Standalone 50% Smaller On Linux

#41
post #8
post #5

This is for native AOT binaries, not for the typical case. Though this release and the previous ones did contain improvements for trimming binaries, which is what you need to use to make non-AOT binaries smaller.

Curious - why isn't it the typical case? .NET runtimes on Linux itself are rare enough, I figured AOT on Linux would be about the only use case, especially in containerized environments.

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 desktop applications.

Thus before .NET Native (UWP only), Mono (iOS/Android), and now Native AOT, doing AOT compilation on .NET was largely ignored, despite NGEN being available.

Re: .NET 8 Standalone 50% Smaller On Linux

#42
post #33

Earlier quoted context omitted.

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…

Calling ServiceStack OSS is disingenuous since it comes with quite a heavy price tag for commercial use.

Not back in the day. IIRC it was mostly FOSS and the author gradually shifted to a more commercial model when MS waltzed all over it with ASP.NET Web API. I’m quite impressed he made it through actually, and I can’t fault someone for going full commercial when a giant moloch whose ecosystem you’re supporting pulls the rug under you like that.

Re: .NET 8 Standalone 50% Smaller On Linux

#43
post #40

Earlier quoted context omitted.

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 with everything you said, except for this part: > There’s this weird misconception in Microsoft land that if you choose .NET you must also use all MS’s half-assed libraries. The way I see it, it's more the opposite really. People chose .NET (or more specifically C#), because, they want to use it's tooling and if you're not going to use it, then why would you pick C#? .NET on it's own is excellent, I'm not sur…

> 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.

Re: .NET 8 Standalone 50% Smaller On Linux

#44
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 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.

Re: .NET 8 Standalone 50% Smaller On Linux

#45
post #8
post #5

This is for native AOT binaries, not for the typical case. Though this release and the previous ones did contain improvements for trimming binaries, which is what you need to use to make non-AOT binaries smaller.

Curious - why isn't it the typical case? .NET runtimes on Linux itself are rare enough, I figured AOT on Linux would be about the only use case, especially in containerized environments.

What does it mean that ".NET runtimes on Linux are rare" ?

They exist, they're easy to install (1), but more importantly for containerized environments, you can start with a standard image e.g. https://hub.docker.com/_/microsoft-dotnet-aspnet

Having the .NET runtime on the target machine isn't one of the pain points in a production deploy.

As others have pointed out, having AOT compilation, with its faster start-up time, along with smaller binaries is aimed at a different perceived pain point: the cold-start performance of lightweight function apps / AWS lambda.

1) https://learn.microsoft.com/en-us/dotnet/core/install/linux#...

Re: .NET 8 Standalone 50% Smaller On Linux

#46

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

> Who is using .NET on Linux?

We don't usually even think about it, but for web apis, function apps and other microservices that process data over http or message queues, it's more or less the default now that the production environment is a linux of some kind. But it isn't a thing that we spend time worrying about.

Re: .NET 8 Standalone 50% Smaller On Linux

#47
post #40

Earlier quoted context omitted.

I agree with everything you said, except for this part: > There’s this weird misconception in Microsoft land that if you choose .NET you must also use all MS’s half-assed libraries. The way I see it, it's more the opposite really. People chose .NET (or more specifically C#), because, they want to use it's tooling and if you're not going to use it, then why would you pick C#? .NET on it's own is excellent, I'm not sur…

> 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 irrelevant for us specifically as we tend to use c/c++ for that.

Re: .NET 8 Standalone 50% Smaller On Linux

#48

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

I'm using the Mono CLR which is a great as a runtime system for statically typed languages; it's lean, efficient and easy to use and deploy (e.g. compared to LLVM), with an integrated, cross-platform debugger. It runs even on old embedded Linux images. Dependency on the .NET framework is possible, but not necessary.

Re: .NET 8 Standalone 50% Smaller On Linux

#50
post #24
post #18

Earlier quoted context omitted.

What language and frameworks has your business shifted into? How has that better fit the goals of speed of development and maintainability?

We’re switching into Powershell for operations. With azure automation. We’re switching to Go for concurrency. C and C++ for computation (though to be fair, we were already doing this with C# and the integration between them has always been great). Our generalist language has become TypeScript however. Not because it’s great technically, but because it lets us share resources better which in term has made us much more…

What does Go offer that C# does not? Both have actors, channels, threads, etc.
Post reply on HN