Hacker News Reader

Comment by setquk | Hacker News Reader

Excellent.

I look forward to all of our .Net Framework only 3rd party dependencies being unsupported and abandoned instantly because there's no way anyone is going to bother supporting two distinct platform versions.

And also the humongous porting effort to move everything over if we want something that isn't half arsed and abandoned which is what happens in the long tail of any MSFT product cycle. When you phone partner support because something is broken and no one knows how to help you.

Another "fuck you" from MSFT. Just like that whole opt-out telemetry crapfest.

I want off this crazy train now. Anyone need a Python/C developer (where knowledge is valuable for more than a 3 year window)?

View on HN

.NET Framework isn't going anywhere. Keep using it if you need to.

Why do you want/need to port something if it's already working fine?

As a Python developer, are you actually surprised by breaking changes?

The Python 2/3 split originated a decade ago, after all.

Python 3 was released a decade ago.

Python 2 is still supported until 2020.

2to3 exists.

Python actually give a shit about their users.

What a lot of people seem to forget about .Net is that for those of us who have been around since day one, we've been burned over and over again by large product and framework deprecations over the years. This is one too many.

.Net Framework (and ASP.NET) will be supported forever.

This is just about the specific combination of ASP.NET Core on .Net Framework, which will be supported until 2021, possibly longer.

> burned over and over again by large product and framework deprecations over the years.

What large framework deprecations? I've been around and I don't feel burned at all.

Assuming Microsoft ends .net framework at 4.8 that effectively ends new features. Although older code will keep working for the most part isolated that isn't the real issue. For example I ran into an issue last year where we had to retarget all of our .net 3.5 projects to at least 4.5 to support tls 1.2. Had that upgrade path not been available we would basically have had no other option but move to a new platform. Even though bug fixes can happen older code will effectively rot with time as other things improve.

Software rots just like physical products. Ongoing maintenance is required. Why would you expect old applications to be compatible forever?

> Software rots just like physical products.

No, it doesn't.

It may become less relevant/useful as market conditions change (like physical products), but it (apart from physical media it is stored on) doesn't also itself degrade over time the way physical products all do at varying speeds.

The binaries will run, but the world changes and if you want to keep up with those changes then the software needs maintenance, which is obviously the topic of discussion here.

> The binaries will run, but the world changes and if you want to keep up with those changes then the software needs maintenance, which is obviously the topic of discussion here.

Physical products both rot (degrade with time) and become obsolete. Maintenance addresses the former problem, redesign and upgrades address the latter problem.

Software becomes obsolete like physical products (and so needs redesign and upgrades), it does not rot like physical products (and so does not need maintenance.)

Software “maintenance” is a misnomer, and the idea that software “rots like physical products” is wrong or, at best, a poorly chosen metaphor, since what it does do is at best loosely analogous to rotting, but exactly the same as becoming obsolete, which is something physical products also do, so rotting is not the closest physical-product analog to what drives the need for continuous attention to software.

Fine then, the software is becoming obsolete as the environment changes. The original comment used "rot" so I continued, because I'd much rather have a productive discussion than a pedantic one.

WCF, WWF, UWP, AppFabric, EF incompatibility etc etc.

Basically the entire enterprise stack.

And I’m not even talking about the whole original .net and com stuff.

I feel similar. Espeically when you do desktop development it's hard to avoid being cynical about any Microsoft "innovation".

I'm using WCF on .NET Framework. The whole enterprise stack is still there.

Yes but the clock is ticking on its demise.

Python 2/3 split had the real technological causes for it to be made.

In contrast, .NET Framework/Core split is mostly political.

Definitely not.

The original framework had decades of legacy and it can't just be redesigned without a major rewrite, which is not realistic or possible given the time and stability constraints. .NET Core is a new runtime with major differences (being cross-platform as a big change). This is much more technologically driven than Python 2/3 was.

You call it legacy. Many people call it the code their businesses rely on.

There is no need to rewrite it, god forbid. Instead, make it cross platform when possible, or exclude from shipping to other platforms.

Then, instead of shipping a segregated .NET Core infant, MS could (and still can!) ship .NET 5.0.msi, .NET 5.0.dmg and .NET 5.0.deb/rpm distributives.

Easy. No need to increase the amount of pain in this world. Just small, incremental, mindful steps towards the greater benefit of all living beings.

.NET framework isn't going anywhere. It'll be supported for years, if not decades, and will likely outlast many of the companies using it. What exactly is your concern?

Just because you use the word "easy" doesn't mean it is. I'm sure the .NET dev team understands their platform and created a new runtime as the most viable option to get all the new features and flexibility of .NET Core.

>I'm sure the .NET dev team understands their platform

They don't. People who initiated .NET Core are web devs. Good web devs. But they are million miles away from understanding the purpose, role and aim of the platform.

The guys who really got it are Sir William Gates, Mr. Steve Ballmer and Mr. Anders Hejsberg, to name a few. They shifted to other interest areas unfortunately.

Regarding the word "easy". Let's take a wider perspective. It should be easy for customers, right? There are a lot of them, say 10 million people. Making things easy is hard. So it gets hard for .NET dev team, say 50 people. The outcome: 10 million happy people, 50 people in pain.

Let's take a look at the current .NET Core approach: kind of easy for 50 people in .NET dev team. But hard for 10 million of customers. The outcome: 50 happy people, 10 million people in pain.

What outcome would you choose?

yep. powershell is similar. because of the ongoing changes to .net underneath, moving to version 6 means supporting 2 versions; the legacy windows version (with all the modules), and the new .net core version. but because it's dynamically typed, its basically 1 million footguns.

Reply on news.ycombinator.com