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

291–300 of 374 posts

Re: .NET 8

#291

Post by WorldMaker »

blackoil wrote: post #33
jordigh wrote: post #13

Can I get an explanation of the relationship between .NET and Mono? I have vague memory of reading somewhere that Mono or maybe just MonoBuild was completely obsolete since everything was now open source in .NET. Does Mono still have a reason to exist? Is it all incorporated into .NET now? (btw, I still don't get why it's called .NET, and I don't know if assemblies are native code or bytecode wrapped in the same bina…

In olden days .net was Windows only. Mono was an independent effort to build a cross platform runtime. With .net core MS made it open source and cross platform. They also bought Mono but that is more or less abandoned I believe latest versions of .net run well on Linux and Mac and now also in browser. They have also dropped Core from the name and there is only one .net which is open source and cross platform. Edit: s…

Mono wasn't abandoned so much as "code merged" (a beauty from that both are now open source). Mono merged into the main .NET repo and the best parts of it became "a single runtime". There are still useful parts of Mono left that aren't exactly inside the "a single runtime" yet, but the amount of "Mono code" shrinks with each version and the more it is all "just" .NET.

Re: .NET 8

#292

Post by WorldMaker »

nerdix wrote: post #257
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.

More important than being open source was the fact that it was Windows only for the first 15-ish years of its existence. Mono never got traction within the startup culture. In part, because it operated in a legal grey area for many years regarding MS patents for web (or web adjacent) technologies like ASP.NET and ADO.NET.

Microsoft made some extremely generous patent grants to Mono and several major Linux Distributions relatively early in Mono's history. Microsoft didn't seem to want to repeat the mistakes that led to their divorce with Java and the early foundations of .NET with their relationship with Mono. In my experience of it, most of the "legal grey area" concerns around Mono for a lot of its history was either truly outdated/ignorant advice or intentional FUD from antagonists (many of which just hated anything Microsoft indirectly touches no matter what).

Re: .NET 8

#293

Post by neonsunset »

poulpy123 wrote: post #279
neonsunset wrote: post #131

Earlier quoted context omitted.

It would. Compiling .NET binaries to a single executable that does not require installing a runtime has been a thing for quite some time actually, but NativeAOT definitely improves the "simple and lightweight" part of your inquiry: JIT: dotnet publish -p:PublishSingleFile=true -p:PublishTrimmed=true AOT: dotnet publish -p:PublishAot=true

Looks interesting! Does nativeAOT works for GUI ?

It's a bit of a hit and miss as of today. CLI, back-end and natively compiled libraries (think dll/so/dylib or even .lib/.a - you can statically link NAOT binaries into other "unmanaged" code) work best, GUI - requires more work.

Avalonia[0] and MAUI[1] have known working templates with it, but YMMV.

[0] https://github.com/lixinyang123/AvaloniaAOT / https://github.com/AvaloniaUI/Avalonia/

[1] https://github.com/dotnet/maui (try out with just true in csproj - it is known to work e.g. on iOS)

Re: .NET 8

#294

Post by Const-me »

GordonS wrote: post #171
gettodachoppa wrote: post #118

Earlier quoted context omitted.

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

> I had high hopes for it become the best story for crossplatform development, it still feels like the crossplatform is held by ductape. Sorry to be pedantic, but it's cross-platform GUI that still doesn't have a good, officially supported story. For non-GUI apps, cross-platform works very well! I've deployed a range of apps to production across Windows, Linux (both x64 and ARM), and Docker on Linux too (also both x6…

> cross-platform GUI that still doesn't have a good, officially supported story

Yeah, but in the meantime there’re decent unofficial options. Once I compiled NanoVG into a DLL, consumed with C#, and implemented rich GUI on top of that. Worked pretty good overall. Eventually I’ve patched NanoVG for optimal font quality on low resolution touch screen of my target Linux device: https://github.com/Const-me/nanovg

Re: .NET 8

#295

Post by WorldMaker »

croes wrote: post #137
meibo wrote: post #53

Earlier quoted context omitted.

This is not unusual in Microsoft-land. If a tech stack or version is very widely adopted or heavily revamped in a new version, they will often support that old version for a very long time - see Windows 7.

No problem with LTS but why the confusing name scheme. Just like their Xboxes.

The name scheme was confusing only during the "overlap" period. At this point again you can strictly pay attention to version numbers: 8 > 7 > ... > 4 > 3 > ...

Any version current LTS. The rest of the "naming scheme" is dead weight.

Re: .NET 8

#296

Post by WorldMaker »

hollerith wrote: post #290
WorldMaker wrote: post #284

Earlier quoted context omitted.

Also, why would force error returns without also including some sort of nice Monadic do-notation or Monad-inspired combinator syntax sugar in the 2020s? We've known for decades now how do that better. I also think that Go looks like a practical joke that escaped some INTERCAL-like satire committee in the 1970s.

You probably mean sum types and convenient syntax for testing and de-structuring sum types.

No I specifically meant what is often called the Either or Result Monad. These are often implemented as Sum types, but they also follow the Monad laws and supports things like monadic binding/transformation/combination and benefit from syntax sugar like Haskell's "do-notation"/OCaML family's "computation expressions"/the "async/await" pattern of so many other languages now.

Good sum types destructuring would probably also be useful in more languages like Go, but many languages today provide "async/await" pattern syntax benefits without anything at all like "proper" sum types. Sum types are "merely" a possible implementation detail of the Monad and it's the Monad laws that empower some things beyond just sum types.

Re: .NET 8

#297

Post by mathverse »

Errsher wrote: post #84
mathverse wrote: post #55

Earlier quoted context omitted.

Microsoft seems weird tho. They dont really support any recommended way to do .NET on Mac and you have to rely on Rider or half ass VS Code experience.

Is it "wierd tho" that Microsoft would have better support for development tools on their own OS than on a competitor OS?

It's absolutely weird because that ship has sailed. The paradigm is to hook you into the platform which you can't do if you are hostile.

Re: .NET 8

#298

Post by jen20 »

chrisandchris wrote: post #100
Thaxll wrote: 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.

I don't know Go that much, but the part about .Net is so untrue. First, C# was published in 2001, while Go was released in 2009. So there's 8 years of "more stuff". Also (see in comments too), upgrading .Net is very easy. There are man not-to-small codebases can be "easily" upgraded from .Net Core 3 to 8 without any hassle. Backwards comptability was always baked into Microsofts thinking. .Net 7 and 8 did also (IMHO)…

The real problem was upgrading from .NET Framework, or Mono, to .NET Core, which has been stable since.

That comparison is not a fair comparison to Go, which has a much stricter guarantee around source and library compatibility within the 1.x series.

Re: .NET 8

#299

Post by neonsunset »

pjmlp wrote: post #286
geodel wrote: post #217

Earlier quoted context omitted.

How is Graal better. Half of the Java ecosystem wouldn't work with Graal.

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-us/dotnet/core/deploying/nati...

Re: .NET 8

#300

Post by Smaug123 »

terandle wrote: post #238
Metasyntactic wrote: post #168

Earlier quoted context omitted.

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 tho…

The new array literals seem to supersede some previous syntaxes like new[] { 1, 2, 3 } goes to [1, 2, 3] in a lot of cases. But overall they are a _great_ addition to the language playing around with them now so bravo. Still not really sure how I feel about class primary constructors on the other hand, will give them some time to marinate.

Class primary constructors have always been the default thing in F#, and I found it deeply annoying not to have them whenever I had to write C#, for what it's worth!
Post reply on HN