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

The future of .NET Standard

devblogs.microsoft.com

Post reply on HN
Print view View original

51–60 of 84 posts

Re: The future of .NET Standard

#51

Post by apta »

iso8859-1 wrote: post #42
apta wrote: post #37

Earlier quoted context omitted.

golang isn't really a threat. It's a weak language with a very messy ecosystem. They don't even have proper versioning figured out, not to mention a proper package manager.

It capturing the minds of youth way faster than .NET did. Package management is an absolute mess on NET too. I was working on a project that had to work with old Mono versions, so it still used packages.config. Behold this mess: https://docs.microsoft.com/en-us/nuget/reference/packages-co...

> It capturing the minds of youth way faster than .NET did

It's because of hype. When analyzing things objectively, the unsubstantiated claims of the golang team quickly collapse. This is coming from someone who saw the mess that golang created in real production systems, which would not have happened in languages like Java and C#.

Mono isn't .NET. Using nuget in Visual Studio or IntelliJ Rider is a breeze.

Re: The future of .NET Standard

#52

Post by conscion »

MikeTheGreat wrote: post #19

"net5.0-windows (and later net6.0-android and net6.0-ios). These TFMs represent OS-specific flavors of .NET 5 that include net5.0 plus OS-specific functionality." Wait - net6.0- is actually net5.0?

There's a table further down in the article that shows more clearly that net6.0-android is part of .NET 6

https://devblogs.microsoft.com/dotnet/the-future-of-net-stan...

Re: The future of .NET Standard

#53

Post by register »

goto11 wrote: post #48
Todd wrote: post #23

This is good news for experienced .NET developers and newcomers alike. It marks the end of the journey from legacy .NET Framework to fully open source cross-platform .NET. .NET Standard was confusing, and the ubiquitous TFMs in the early days were even more so. But all of those struggles where made to achieve a cross-runtime compatibility layer to make it easier to support both ecosystems. It was a Herculean effort b…

I fear it marks the beginning of a very long dark journey, where .net developers are forced to work on more and more obsolete software while looking with envy towards other platforms which are actually maintained. The "core" migration is not a problem for short-lived startups, but .net is used a lot in business and enterprises. They don't rewrite their whole stack every two years but prefer an incremental approach. S…

That's not my experience. Enterprises usually schedule far in advance budget specifically for the sole purpose of upgrades. Every product has a life of end support and projects to move to the next version are a reality in the enteprise market that brings a lot of money to the table. For .NET it will be exactly the same.

Re: The future of .NET Standard

#54

Post by qz2 »

bookshelf976 wrote: post #36
qz2 wrote: post #11

This is the most schizophrenic platform I've ever worked on. I've just spent an hour trying to make something work across the five different variants and web pipelines doing things underneath. Edit: to be clear we have completely hung legacy stuff which is waiting resources (lots of $$$$ wasted) to port it to later versions of the frameworks because huge chunks of the ecosystem got abandoned by MS and the OSS develop…

What do you mean by five different variants? Also, what are the chunks of the ecosystem that were abandoned? Web Forms? Silverlight? UWP? Microsoft has shown an amazing ability to modernize and improve the platform without dragging baggage around from one version to the next. We just took an ASP.NET MVC web app developed in 2005 for Windows/IIS and shipped it on linux using .NET core— the conversion took 1 developer…

Trivial projects yeah. This is not a trivial project.

As for different variants. Two different http pipelines (classic, integrated), OWIN, one obsolete variant of OWIN, whatever is lurking inside .Net core now. WebAPI, MVC, bits of the remains of WCF floating around.

Abandoned bits: WCF, WWF, older OWIN pipelines, SignalR and a huge chunk of open source projects and commercial CLR packages.

It's a shit show it really is.

Re: The future of .NET Standard

#55

Post by [deleted] »

iso8859-1 wrote: post #42
apta wrote: post #37

Earlier quoted context omitted.

golang isn't really a threat. It's a weak language with a very messy ecosystem. They don't even have proper versioning figured out, not to mention a proper package manager.

It capturing the minds of youth way faster than .NET did. Package management is an absolute mess on NET too. I was working on a project that had to work with old Mono versions, so it still used packages.config. Behold this mess: https://docs.microsoft.com/en-us/nuget/reference/packages-co...

[deleted]

Re: The future of .NET Standard

#56

Post by igouy »

thesuperbigfrog wrote: post #16
kasperni wrote: post #7

Earlier quoted context omitted.

Some of the .Net examples literal calls into native code. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... vs https://benchmarksgame-team.pages.debian.net/benchmarksgame/... That is hardly a fair comparison.

Agreed. A fair comparison would use .Net code and not call the PCRE2 library. Otherwise, why not use JNI and have it call PCRE2 as well?

Please write and contribute that PCRE2 Java program.

Meanwhile here's a C# program that does not use PCRE2:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: The future of .NET Standard

#57

Post by cptskippy »

kyberias wrote: post #38
cptskippy wrote: post #33

Earlier quoted context omitted.

Unless you're old enough to remember when everything was named .NET (e.g. Office.NET, Windows.NET).

It was a very very short time.

It was a few years, but that's MS pattern. Now days everything is either o365 or Azure branded.

Re: The future of .NET Standard

#58

Post by igouy »

kasperni wrote: post #7
akmittal wrote: post #3

Microsoft is making lots of performance improvements on .Net Core side. It seem to be lot faster than Java now. With .net core being open source and Cross Platform I think it is still not able to take Javas marketshare. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Some of the .Net examples literal calls into native code. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... vs https://benchmarksgame-team.pages.debian.net/benchmarksgame/... That is hardly a fair comparison.

As it says — "These are only the fastest programs. Look at the other programs. They may seem more-like a fair comparison to you."

Re: The future of .NET Standard

#59

Post by WorldMaker »

jimbob45 wrote: post #17
Someone wrote: post #2

Earlier articles in this ongoing series of “how to name things”: - September 2016: Introducing .NET Standard ( https://devblogs.microsoft.com/dotnet/introducing-net-standa... ) - May 2019: .NET Core is the Future of .NET ( https://devblogs.microsoft.com/dotnet/net-core-is-the-future... ) - May 2019: Introducing .NET 5 ( https://devblogs.microsoft.com/dotnet/introducing-net-5/ ) (Yes, the last two are from the same mo…

What’s so weird is that DirectX has an entirely terrestrial naming system and .NET refuses to follow its example.

With .NET 5 things are going back to a "check the version number" naming system though. 5 is greater than .NET Core 3.x, .NET Framework 4.x, and .NET Standard 2.x, you can pretty much forget what Core/Framework/Standard entirely mean as soon as you can upgrade to 5. (And the next version is .NET 6.) It's one version number left now.

(Also, DirectX tried to version number individual components at various points in its history so even DirectX "naming" isn't that straightforward at certain points in time in the past.)

Re: The future of .NET Standard

#60

Post by teh_klev »

As someone who was somewhat out of the loop for a couple of years with regards to .NET/Core etc and the "Standard" thing, I had kind of wondered what all these new "Standard" options in Visual Studio meant and after a couple of hours of Googling it made sense.

I think there's a few folks out there who make a wee bit of a mountain out of a molehill when it comes to this "unification" effort by Microsoft to deliver I guess "the one .NET to rule them all".

Now sure it's been a wee bit painful (no less probably than for those working on .NET itself) to get to this stage, but .NET has been around for a lot of years, welded for most of its life to Windows and this transformation wasn't going to happen overnight. But having the "Standard" TFM bits has gone some way during this time to mostly ensure your code can be compiled an deployed to "any platform" albeit with some caveats and some warts.

I think .NET-5 is a reasonable step in the right direction. And for those of us working on .NET 4.x projects that still need to be looked after (I work on a pretty sizeable .NET 4.7 app) well MS will be supporting the "Windows .NET" for a good few years to come.

I should say that whilst .NET and Windows are my rent-paying tools-of-the-trade, I'm not a fanboi and have my own beefs and criticisms about MS's tooling decisions. Don't get me started about EF, especially Enum handling from back in the day.

And yes, sometimes (in fact many times) MS do somewhat cack-handedly mess up naming things which doesn't help.

Post reply on HN