Live data from Hacker News

.NET 8

devblogs.microsoft.com

161–170 of 374 posts

Re: .NET 8

#161

Lots of very cool stuff here (AOT, Aspire, etc.). .NET has been held down by the image of its early days, but it has become a pure joy to work with recently. The improvements in tooling and ergonomics have made it a replacement for Go in our org (we migrated from .NET Core 3.1 to Go back to .NET 6 recently).

> .NET has been held down by the image of its early days, but it has become a pure joy to work with recently People have been saying that for the past 4 years. As someone who's never used .NET but develops embedded apps for Linux, I had high hopes for it become the best story for crossplatform development, it still feels like the crossplatform is held by ductape. It's still Xamarin for mobile, Avalonia (a 1-man proje…

Windowing and Widgets; those are the two things that always seem to be the biggest issue for cross-platform apps that should be trivial if the groundwork were in place.

I solidly blame MS for shipping something like 10+ of their own frameworks and never E.G. including QT or anything else open. Apple's just as bad, if not actively worse, for relegating even open 3D modeling languages to second class.

Re: .NET 8

#162

I'd love to hear from some .NET fanatics, how would you convince someone to use that ecosystem over another?

I've used .NET for work forever, but I also utilize it for hobby projects. I can write and install a small C# app on a Raspberry Pi Zero 2 to do various tasks around the house. Very handy and straightforward.

Re: .NET 8

#163
post #59

Earlier quoted context omitted.

The .Net ecosystem has a lot of great tooling, for sure. The main issue I have had is if you are trying to get into the .Net Ecosystem without spending money. There are quite good free tools, but you have to figure out what works best for you if you're used to the non-free ones. I assume instead of Reflector for the decompilation, you used DotPeek?

I've used ILSpy instead of JetBrain's tools for this. If you're a real OG, you used `ildasm`.

I learned this from Jeffry Ritcher (https://www.amazon.com/CLR-via-C-Developer-Reference-ebook/d...)

A lot of what I know about C# is from his books. I wish every language had someone of his caliber write a book about it.

I think the version of the book I read was "CLR via c#" about 10 years ago

Re: .NET 8

#164
post #4

Tangentially related but I was impressed with .NET recently. I was recently tasked with tackling an extremely old and proprietary video format that embedded GPS, video, audio, and several other components. The files were huge and just a mess to understand and I eventually found an old player application that was also proprietary. I decompiled it into C# and stripped the player aspect out of it leaving the code the pe…

Microsoft has lot of issues but when it comes to Backward compatibility, no one comes close to them. Solid.

Re: .NET 8

#165

Earlier quoted context omitted.

> The main issue I have had is if you are trying to get into the .Net Ecosystem without spending money. I suggest not trying to do this. You can certainly make most of .NET8 work with a pure OSS toolchain, but your overall development experience is going to be destitute compared to that of the official tool chain. To be clear - I think paid alternatives, such as Rider are fantastic too, but even so I've had some trou…

What would you say is the current best in class toolchain for .NET (assuming I'm running on a ARM Mac)?

Jetbrains’ Rider by a very long shot

Vscode stuff is ok too if you dislike big and featureful ides, but it’s behind rider. dotnet cli to run commands is sufficient until you have very strange builds.

Keep in mind the language has many ways to do the same thing, so rider helps you doing the “modern” things. The base class library is also very vast. Take your time, C# is great but it has a ton of features.

Re: .NET 8

#166
post #51

Earlier quoted context omitted.

Big difference is that Go is stable and conservative, net core keep adding a billion features every release. Looking at some net core 2/3 stuff and now to see how many things changed. Good luck with your code base in 5 years when someone decide to add all the new stuff.

.NET is stable, they very rarely remove things. Code written for .NET Framework 2.x will probably work fine on .NET 8 (unless it uses the things that didn't make the jump, like WCF, but there are libraries that provide SOAP support.) Can a single developer remember all of .NET? No, but that applies to most languages/ecosystems. But if you encounter something you've never seen, you can always check the docs. And the t…

Ehh, that is the thing about Go, most Go developers know most of the std (compared to other languages at least)

Re: .NET 8

#167

Earlier quoted context omitted.

UI frameworks are a heavy lift, more-so to be cross-platform. Let's say someone tries, but it's not to your liking? I mean, there can't be 12 different frameworks, that's not sustainable.

I am really flexible in terms of a toolkit's ergonomics. But I am running into situations where things just straight up don't work (Java/graalVM), or that I need to implement some really basic interaction and there is no guidance in the documentation and the abstractions don't make any sense. (Avalonia) And that's assuming it even compiles or packages. So far the only winner has been QT (via pyside6 for me)

I get it. And I completely agree on Avalonia. Personally, I'm not a big fan of that style programming where xml-ish glues stuff together. Makes hunting down errors a nightmare.

Re: .NET 8

#168
post #51

Earlier quoted context omitted.

Big difference is that Go is stable and conservative, net core keep adding a billion features every release. Looking at some net core 2/3 stuff and now to see how many things changed. Good luck with your code base in 5 years when someone decide to add all the new stuff.

.NET / C# seems to be following C++ by including... everything. I wonder if they're just not worried about feature bloat or what's their thinking...

Hi there, C# Lang Designer here. :)

We're always thinking about the bloat concern when it comes to language development. However, our philosophy on it is that bloat primarily comes when you add replacement systems that are expected to supersede the previous mechanisms, not compliment them. So we try to do the former sparingly. In the history of C# there are very few times we've actually done this, and we do view those times as unfortunate cases where we likely rushed a feature too early and then regret having to live with those features forever.

To help combat this, we tend to go through long periods of design and experimentation, where we propose features, create prototypes of them, and then interact with a large set of diverse community groups to try things out. The feedback from this is tightly bound into our design process and allows us to refine (or even jettison) designs rapidly.

We also normally will both break up work into lots of smaller pieces (composing large language changes into small orthogonal, complimentary, composable blocks), and do designs over many years if appropriate. We think this approach has helped us create a language that is 25 years old, while being both very rich, and still very cohesive. There are a few mistakes we've made along the way ("anonymous-delegates", i'm looking at you), but we're very happy that our ratios here are very good given our continued investment in this space.

Re: .NET 8

#169
post #59

Earlier quoted context omitted.

The .Net ecosystem has a lot of great tooling, for sure. The main issue I have had is if you are trying to get into the .Net Ecosystem without spending money. There are quite good free tools, but you have to figure out what works best for you if you're used to the non-free ones. I assume instead of Reflector for the decompilation, you used DotPeek?

> The main issue I have had is if you are trying to get into the .Net Ecosystem without spending money. I suggest not trying to do this. You can certainly make most of .NET8 work with a pure OSS toolchain, but your overall development experience is going to be destitute compared to that of the official tool chain. To be clear - I think paid alternatives, such as Rider are fantastic too, but even so I've had some trou…

[deleted]

Re: .NET 8

#170

Seems like AOT compilation is spotty on Asp.NET apps. A fresh app made with dotnet new webapi -o aot-api did not work when run.

I haven't completely followed the AOT stuff, but I remember hearing some stuff about some reflection-heavy code doesn't play well with AOT.

But .NET has a great option in this case: ReadyToRun. Basically, it AOT compiles a ton of stuff, but also creates the byte code which can be JIT optimized at runtime. The file output is larger which is a downside, but is usually a very minute downside. ReadyToRun takes care of start up times because you have the machine code to get things running fast. Plus, the JIT can sometimes make optimizations that can't be done at compile time so you can end up with better overall performance (at the cost of a larger executable file).

One of the things that is nice about .NET is that a lot of things come with sustained, multi-year effort with some good things coming every year. Microsoft is working on making more and more of .NET AOT-friendly and really upgrading the way things are done. Along the way, there are things like ReadyToRun which work really well for what most people want/need.

Post reply on HN