Live data from Hacker News

.NET 8 Standalone 50% Smaller On Linux

learn.microsoft.com

131–140 of 179 posts

Re: .NET 8 Standalone 50% Smaller On Linux

#131

What the .NET team does on the technical side is almost universally wonderful. They've (ironically?) been a bit more successful than the Java folks at establishing multiple serious languages of different kinds running on and interoperating via the same runtime. But it's still a Microsoft project and their sword keeps looming over its head. There have been some heavy-handed anti-developer choices in the past and one c…

> They've (ironically?) been a bit more successful than the Java folks at establishing multiple serious languages of different kinds running on and interoperating via the same runtime. Can you explain more? I'm less familiar with the .net side of things.

not OP, but I'd guess they are referring to F# and C# interoperability. It's trivial to call into each other from within the same project. I'm not as familiar with this on the JVM side myself. How easy/common is it to have multi-language projects? Because in .NET it's very common to have C# interface to F# projects and vice versa with minimal work.

Re: .NET 8 Standalone 50% Smaller On Linux

#132

Earlier quoted context omitted.

Do C# channels offer lightweight concurrency ? The defining feature of Go is only matched by Erlang/Elixir and now Java. AFAIK C# has nothing like it.

C# approach to concurrency has always been better since its introduction. It does have Channels which offer more focused pattern for SPSC, MPMC, etc. scenarios but neither Java nor Go offer a comparable level of ease of use as C#’s hot-started tasks: // The tasks will run in parallel var data = service.GetData(id); var user = service.GetUser(name); Handle(await data, await user); Re: the above comment on switching to…

There is no async coloring in Go. In the example you cited above, service.GetData can be a plain synchronous function in Go. You don't need to distinguish between sync/async as this is defined by the caller and not by the callee. Any function can be made asynchronous without changing its signature. That's one of the critical advantages of having first-class concurrency. There is no "function coloring".

The simplicity of this approach and the advantages this brings to code structuring and easy refactoring simply cannot be understated.

Re: .NET 8 Standalone 50% Smaller On Linux

#133

Earlier quoted context omitted.

> Rider can be pretty heavy but Apple Silicon eats it up. (And to be fair to Rider, it was still pretty good even on Intel machines). Rider (like all JetBrains IDEs) gobbles RAM and sometimes needs its time to think. But what makes it so, so much better than Visual Studio (besides a minimum of effort spent on usable design) is that it doesn't randomly completely lock up the UI for several (sometimes tens) of seconds.…

The startup time of JetBrains Rider is so nice & quick. Going back to using Visual Studio 2022 after two years on the latest Rider version felt sluggish in a bunch of ways.

This hasn't been my experience lately. Are you perhaps comparing VS 2022 with Resharpen against Rider? Stock VS 2022 is quite a bit faster than Rider for me. And for the missing refactorings there is Roslynator.

Re: .NET 8 Standalone 50% Smaller On Linux

#134

Earlier quoted context omitted.

C# approach to concurrency has always been better since its introduction. It does have Channels which offer more focused pattern for SPSC, MPMC, etc. scenarios but neither Java nor Go offer a comparable level of ease of use as C#’s hot-started tasks: // The tasks will run in parallel var data = service.GetData(id); var user = service.GetUser(name); Handle(await data, await user); Re: the above comment on switching to…

There is no async coloring in Go. In the example you cited above, service.GetData can be a plain synchronous function in Go. You don't need to distinguish between sync/async as this is defined by the caller and not by the callee. Any function can be made asynchronous without changing its signature. That's one of the critical advantages of having first-class concurrency. There is no "function coloring". The simplicity…

Deferring to function coloring terms usually indicates a skill issue of not understanding that types are meant to represent what the code actually does.

Task-returning method indicates an asynchronously produced (deferred/delayed) result, a promise. If a language hides this fact (that the returned value needs to be awaited), it is grossly misdesigned - at most it can offer not blocking a thread, completely missing the point and leaving 20 years of improvements other programming languages have on the table.

But it's not as bad, yet instead in many other languages you are forced to manually schedule and then block/join until all of your tasks/promises/goroutines finish. Not in C#, that makes it as easy as it gets, which you can see in my example.

On top of that, you always pay for concurrency in Go, even when you don't use it, it is by definition always "colored" which further contributes to the overhead.

Also, in my example, the tasks will run in parallel. They won't in Go.

Re: .NET 8 Standalone 50% Smaller On Linux

#135

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

At my company, every api server and azure function is executed in k8s as linux container. The license costs and performance footprint are a huge factor to not run on windows. And docker-images for the CI production. Linux is just so much better IMHO. I would switch to linux if visual studio (not vscode) would run there natively.

try out Rider, you'll love it

Re: .NET 8 Standalone 50% Smaller On Linux

#136

Earlier quoted context omitted.

I am. I've been developing with .NET since the start and my current workflow is really the smoothest and most productive (and most enjoyable!) I've ever had: I develop solely on Mac (JetBrains Rider), compiling/debugging Mac binaries locally - no containers - unless I need any external dependencies like eg. Postgres. On M1 MacBook Pro the experience is blazing fast - and Rider can be pretty heavy but Apple Silicon ea…

> Rider can be pretty heavy but Apple Silicon eats it up. (And to be fair to Rider, it was still pretty good even on Intel machines). Rider (like all JetBrains IDEs) gobbles RAM and sometimes needs its time to think. But what makes it so, so much better than Visual Studio (besides a minimum of effort spent on usable design) is that it doesn't randomly completely lock up the UI for several (sometimes tens) of seconds.…

I haven’t had VS lock up on me in ages. Probably since version 2019. A ton of work has been done to move everything out-of-process (and in doing so, make it async) and remove synchronous hooks.

Are you using 3rd party extensions? ReSharper? Lots of badly written (even tiny extensions that you’d think would be basically no-ops) can make VS lock up again.

Re: .NET 8 Standalone 50% Smaller On Linux

#137

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've used it exclusively on my servers for the last 5 years and am now using it on my laptop.

Server side, it's better than running it in Windows. I don't pay a license fee for the OS, so spinning up new VMs is super easy. And set-up, deployment, and long-term operation have all just gone off without any hitches. I've got Let's Encrypt certificates, Postgres databases, and so little overhead that I can't get by with small server SKUs.

On desktop, I still use Windows at work, so I've built a WPF/WebView2 and a GTKSharp/WebKit web app shell that lets me run identical code to my server apps, just as a desktop app. It was pretty fiddly to setup (mostly because GTK is hot garbage), but now that I have it, it just works.

Re: .NET 8 Standalone 50% Smaller On Linux

#138

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 suppose it depends what you mean by linux, but if aws lambda on linux counts, then i work at a top 250 UK company who uses dotnet heavily for lambda workloads, especially async workloads. Its been great for us, no complaints. We likely would use it for our sync apis too if dotnet supported apollo federation v2, but sadly it does not.

Re: .NET 8 Standalone 50% Smaller On Linux

#139

Earlier quoted context omitted.

> They've (ironically?) been a bit more successful than the Java folks at establishing multiple serious languages of different kinds running on and interoperating via the same runtime. Can you explain more? I'm less familiar with the .net side of things.

not OP, but I'd guess they are referring to F# and C# interoperability. It's trivial to call into each other from within the same project. I'm not as familiar with this on the JVM side myself. How easy/common is it to have multi-language projects? Because in .NET it's very common to have C# interface to F# projects and vice versa with minimal work.

It’s extremely easy. I have no idea what OP is talking about. I currently work on a mixed scala/java project. It’s also one of the biggest features of Kotlin, interoperability is seamless.

Re: .NET 8 Standalone 50% Smaller On Linux

#140

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 suppose it depends what you mean by linux, but if aws lambda on linux counts, then i work at a top 250 UK company who uses dotnet heavily for lambda workloads, especially async workloads. Its been great for us, no complaints. We likely would use it for our sync apis too if dotnet supported apollo federation v2, but sadly it does not.

Have you seen this? https://www.apollographql.com/blog/announcement/backend/anno...
Post reply on HN