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

.NET 8

devblogs.microsoft.com

Post reply on HN
Print view View original

321–330 of 374 posts

Re: .NET 8

#321

Post by davidelettieri »

mdasen wrote: post #255
davidelettieri wrote: post #202

Earlier quoted context omitted.

Microsoft started open sourcing .net framework on 2007 with 3.5 version. The roslyn compiler is open source since 2014. I guess it's fine if people don't like .net but I think the open source part is not that relevant.

I think it depends on who you are. In 2007, a lot of people distrusted Microsoft and with good reason. They'd spent a lot of time extinguishing competitors. .NET Core was initially released in 2016, but Microsoft wasn't saying that .NET Core was their plan for the future. It seemed like an experiment they'd likely kill off or that it might just be a small subset of .NET. I think saying that Microsoft started open sou…

My feeling was that Microsoft open sourced the .net framework to help Mono catchup a bit.

As for access to windows, to be honest I think that's pretty easy to have. Run on general purpose hardware, it's not that expensive.

I think that having access to a Mac is relatively harder than having access to a Windows machine.

When .net core came out I was under the impression that the product was the future of .net but maybe I was living in a bubble.

Anyway, I understand your point but I still think that the disinterest towards .net is tied to a generalized adversion to Microsoft (probably deserved) but not really related to the tech itself nor it's availability on Linux or Mac.

Re: .NET 8

#322

Post by fomine3 »

guhidalg wrote: post #74
RajT88 wrote: 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`.

dnSpy was the best

Re: .NET 8

#323

Post by kaba0 »

imiric wrote: post #230
kaba0 wrote: post #212

Earlier quoted context omitted.

Go is insanely verbose compared to both C# and Java due to its low expressivity, especially around its error “handling”.

I think you're confusing Go's simplicity and explicitness with verbosity. Yes, it won't help you write the least amount of code, but this forces you to write readable code and avoid cleverness, which is almost always a good thing. Its error handling is an exhausted topic, but avoiding exceptions and being forced to decide how to handle errors where they happen is also a good thing IMO. On the other hand, I would abso…

> I think you're confusing Go's simplicity and explicitness with verbosity

I think those are quite innately related, yes. But I believe you also mix verbosity up in your very next sentence, for what it’s worth — readable, maintainable code is not as close a concept. In fact, certain type of verbosity helps readability, e.g. I argue that Go’s identifier capitalization harms readability, and marking it at a single place by public/private is much better, at a tiny price of more verbosity.

“Clever” code is another topic, there is definitely overly clever code, which is a net negative, but in this particular comparison, is a hand-written, 3-times nested for loop with any number of side effecting statements more clear to read than the “smart” stream/linq expression? I would argue the latter is much more readable and maintainable. For another, even better example there is that math proof, which can be done an order of magnitude faster by choosing a clever notation, but I can’t look up its name yet.

Re error handling, no, go doesn’t force you to handle the errors. It forces you to do some stupid meaningless if err ritual, that won’t result in correct handling of the error case, and will in fact often swallow errors. Java’s checked exception does force you to correctly handle it, though, but even runtime exceptions at least bubble up, making the default action (doing nothing) correct.

Re: .NET 8

#324

Post by pjmlp »

neonsunset wrote: post #299
pjmlp wrote: post #286

Earlier quoted context omitted.

Just like with Native AOT, as it only supports CLI, dynamic libraries with C ABI, and a special flavour of ASP.NET with minimal APIs introduced now in .NET 8. Mono AOT supports a bit more, with focus on iOS and Android workloads. None of them work with GUI frameworks or classical ASP.NET applications.

MAUI iOS can also be targeted by NativeAOT[0] and Avalonia has been proven to work with it as well. Also, you can statically link NativeAOT libraries into existing C/C++/Rust/etc. code, and you can statically link existing static libraries into NativeAOT binaries[1]. [0] https://devblogs.microsoft.com/dotnet/dotnet-8-performance-i... [1] https://github.com/lixinyang123/AvaloniaAOT [2] https://learn.microsoft.com/en-u…

MAUI iOS with NativeAOT is experimental, and is still only of target out of many.

Avalonia is great, however the biggest issue is with Microsoft own tech, as many of us are well aware, many companies are Microsoft shops and only care about what is in the Visual Studio box.

There, not only is Native AOT behind .NET Native, there is no plan to ever support AOT in Forms and WPF projects.

On the libraries I stand corrected regarding static linking.

Re: .NET 8

#325

Post by pjmlp »

Semaphor wrote: post #318
pjmlp wrote: post #249

Earlier quoted context omitted.

Python 2 => 3 also has the issue that some things don't exist in Python 3, or are done in incompatible ways. As I mentioned a few times, I have been involved in projects were that full rewrite happened to be .NET Framework => Java, which shows how the customers were mad at what was left behind. Although there is some irony in that, as Java's Python 2 problem is the transition into Java 9.

> as Java's Python 2 problem is the transition into Java 9 Binary incompatibility between 7 and 8 as well, we got an enterprise product that got bought by SAP and will eternally be stuck on Java 7, but at least unlike the other one, it doesn’t require much maintenance as it’s only used internally ;) > Python 2 => 3 also has the issue that some things don't exist in Python 3, or are done in incompatible ways. What doe…

The way unicode was handled, integer division semantics, some libraries went away, and a few other things change enough that 2to3 wouldn't handle everything, which in a dynamic language is a big pain to track down in a huge codebase.

Naturally some changes on the C API for native libraries as well.

Re: .NET 8

#326

Post by Semaphor »

pjmlp wrote: post #325
Semaphor wrote: post #318

Earlier quoted context omitted.

> as Java's Python 2 problem is the transition into Java 9 Binary incompatibility between 7 and 8 as well, we got an enterprise product that got bought by SAP and will eternally be stuck on Java 7, but at least unlike the other one, it doesn’t require much maintenance as it’s only used internally ;) > Python 2 => 3 also has the issue that some things don't exist in Python 3, or are done in incompatible ways. What doe…

The way unicode was handled, integer division semantics, some libraries went away, and a few other things change enough that 2to3 wouldn't handle everything, which in a dynamic language is a big pain to track down in a huge codebase. Naturally some changes on the C API for native libraries as well.

Fair enough, thought that still sounds like things where an upgrade path is available, just not automatically, instead of "you have to throw the code away because it simply doesn’t work anymore".

Re: .NET 8

#327

Post by aryehof »

Been away from .NET for many years. In those days, business logic was largely represented as procedural code using classes for organization, manipulating recordsets or datasets.

Is that still the case?

Re: .NET 8

#328

Post by SideburnsOfDoom »

moogly wrote: post #192
croes wrote: post #36

Earlier quoted context omitted.

Still confusing if can't simply switch to the most recent version or have legacy software. .NET Framework 4.8 will be longer supported than .Net 5, 6, 7 and maybe 8.

> .NET Framework 4.8 It was many a moon ago I even thought about .NET Framework. Not everyone might be so lucky, of course.

Yes, I'm in the good place now where I only have to think about version .NET 6 and up.

I would view it as a major, even terminal red flag if I was offered a job involving .NET Framework 4.8 or lower again.

Re: .NET 8

#329

Post by SideburnsOfDoom »

haolez wrote: post #49
financltravsty wrote: post #8

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

At least until it gains an immense market share and Microsoft starts monetizing it again. They've already tried in .NET Core 7, no? I'm staying away for now.

Microsoft's main monetization strategy is to get people to run their code on the Azure cloud.

If it means running code in any lang, on a linux vm in Azure, so be it.

If it means giving away dotnet, so be it.

If it means that dotnet on AWS is also popular, so be it.

They're pretty clear and open about that, you don't have to look for hidden motives.

Re: .NET 8

#330

Post by SideburnsOfDoom »

rjbwork wrote: post #5

The new interceptors in C# 12 look pretty wild. Will have to play around with them. Was hoping for more of a PostSharp style AOP framework, and this doesn't appear to be that.

It seems though that you're not going to use interceptors to code up your business logic, or at least not without producing unsuitable code.

What they're likely aimed at is scenarios such as DI frameworks where there is currently "serious magic" code that generates code at runtime using reflection and lightweight code gen; and in new AOT scenarios all of this has to be done ahead of time, during compilation, in source generators, without runtime reflection. In other words, if you're not writing such an DI / AOP library, it's not for you.

But if you want to make a "PostSharp style AOP framework" then this is a tool for you to use when building it.

Post reply on HN