4 ms·

> MS really made a grave mistake by coupling the evolution of the C# language to the .NET version. It’s not directly coupled, but each version of C# has a mini

> MS really made a grave mistake by coupling the evolution of the C# language to the .NET version. It’s not directly coupled, but each version of C# has a minimum .NET version it can support, due to the requirements of the features in the language itself (like LInQ in the past). And MS has been very up front about .NET framework being legacy and not getting any future upgrades for years now. Keeping every new C# feature compatible with every obsolete .NET version obviously has a big technical cost. MS has clearly decided it would rather spend its effort to improve C# for those keeping up to date. > It is becoming a a lot less fun to be a C# developer because you more often will have to work with obsolete tools. On the contrary. The language and platform is better to work with than ever and I can do everything I need, on Linux, with just Emacs and the CLI. I couldn’t be happier!

goto11 6y ago
> Keeping every new C# feature compatible with every obsolete .NET version obviously has a big technical cost Strawman there. The problem is not "every obsolete .NET version", the problem is .net in reality have two incompatible platforms at this point, but newer C# versions are only supported on one of them. Going from framework to core will require (risky, expensive) rewrites, which means lots of real-world code will never be migrated. That is just reality. Startups who rewrite their whole tech stack every six months is not the norm outside of Silicon Valley. So for the foreseeable future, .net will have these two platforms in parallel. And unless you are a hobbyist, you probably don't get to decide which one to use. Microsoft have forgotten how important developer enthusiasm is for the success of a platform. Nobody likes to work on legacy code with obsolete tools with no end in sight.
- josteink 6y ago
  > The problem is not "every obsolete .NET version", the problem is .net in reality have two incompatible platforms at this point, but newer C# versions are only supported on one of them. But that’s fairly consistent right? An old platform not getting updates and a new platform getting updates? Why would you expect the SDK of the officially deprecated platform to get updates with the latest compilers and technologies, but at the same time in every other way remain stagnant? Microsoft has been very clear that what you have will keep working, but you won’t get any new toys. If you want those, you have to put in the effort to upgrade your projects, and in worst case rewrite the portions you can’t. > So for the foreseeable future, .net will have these two platforms in parallel. Yeah. The old one not getting updated, used by those who won’t put in the effort to update their tools. And the new one where all the nice things are happening, which really should act as a nice carrot, not a source of bitterness. > Microsoft have forgotten how important developer enthusiasm is for the success of a platform. 99% of the old ASP.NET stack was terrible and unpleasant to work with. The new stuff is nice (enthusiastic!) to work with exactly because they decided to not carry all that stuff forwards. The new APIs was a nice fresh start for the current kind of apps one writes today.
  - goto11 6y ago
    > But that’s fairly consistent right? An old platform not getting updates and a new platform getting updates? I'm not sure what you mean with "consistent", but the problem is of course creating two incompatible platforms in the first place. All previous releases of .net have been largely backwards compatible (except for rare edge cases and security issues), so it remained a single platform where you could get the latest improvement just by upgrading the framework. Of course when you have created two incompatible platforms, it would be double the work to keep both updated, so they have to abandon one. Which is why they shouldn't have done it in the first place. They could have upgraded and deprecated components in a modular manner without creating a whole separate incompatible platform.
    - josteink 6y ago
      > the problem is of course creating two incompatible platforms in the first place Interest in .NET was dwindling because ... it was Windows-only and its APIs and frameworks was a bad fit for the cloud. It was literally heading for a nose-dive. So if Microsoft wanted to address that and make .NET truly cross-platform, they either had 2 options: Port everything which is Windows-specific to all other platforms, or just strip it from the core .NET APIs. If they wanted to make it more cloud friendly, again they had 2 options: Make the already complex APIs, even more complex by trying to shoehorn cloud use-cases into a BCL largely designed for a Windows AD-network kind of security model. Or just start over, with a clean slate, and APIs designed for the age we're currently writing software for. While yes, the latter options creates a new incompatible platform, it's really the only realistic option. And if you're going for the first latter option, you might as well go for the second. I don't think you will find anyone who believes Microsoft would be able to execute on .NET Core as it did, if it had tried to bring all the old legacy along for the ride. > All previous releases of .net have been largely backwards compatible Yes. Which has been a mixed blessing. Look at what a mess classic ASP.Net has become (which ASP.NET MVC is built upon) wrt to page-event life-cycles and what not. Are you not happy to see all that terrible things truly gone, for good? > Which is why they shouldn't have done it in the first place. They could have upgraded and deprecated components in a modular manner without creating a whole separate incompatible platform. But that's what they did, really. They obsoleted classic ASP.NET and WebForms. They obsoleted WCF servers. And they obsoleted the Windows-centric security-model. Anything else? Everything else is still there. The language, the rest of the BCL, the packages you know and love. And you were given years after they said "These technologies are not getting any new updates" to migrate to the new ones (while still on classic .NET Framework), which was kindly published as multi-targeted Nuget-packages, to give you a gradual migration path. Sure. It wasn't perfect, but what is? If anyone is to blame here, it is how people have kept hanging on to classic .NET for years when the writing has been on the wall, hoping that maybe perhaps if they wait for another .NET Core release... That all those terrible technologies everyone is glad to let go off, will be ported to .NET Core too. You know what? It didn't happen, because .NET Core was a community project, and the community didn't want it, or at least certainly not enough to warrant the effort. And not only that! Thanks to being freed from the Windows it was borne into, it has become more vibrant and popular than ever before. It's no longer a technology threatened with extinction. As someone using and invested in .NET yourself, surely you must appreciate that?
- torbica 6y ago
  Exactly this. My current project is on full .NET Framework 4.8. It is on the latest possible version of ASP MVC, Entity Framework and all typical 3rd party libraries(of which 90% is supported on .NET 5). In the last two years we created several POCs for migration to .NET 5. Our current best estimate is 7 years for 80% of our development team. No sane manager will ever approve that crazy effort with almost no benefits for end users. Additionally we are talking here about most typical CRUD application without almost any advanced engineering. Our onboarding is taking at most 2 days and people can start be very productive even in first couple days. I can only imagine nightmares with more complex systems.

goto11 6y ago

> Keeping every new C# feature compatible with every obsolete .NET version obviously has a big technical cost Strawman there. The problem is not "every obsolete .NET version", the problem is .net in reality have two incompatible platforms at this point, but newer C# versions are only supported on one of them. Going from framework to core will require (risky, expensive) rewrites, which means lots of real-world code will never be migrated. That is just reality. Startups who rewrite their whole tech stack every six months is not the norm outside of Silicon Valley. So for the foreseeable future, .net will have these two platforms in parallel. And unless you are a hobbyist, you probably don't get to decide which one to use. Microsoft have forgotten how important developer enthusiasm is for the success of a platform. Nobody likes to work on legacy code with obsolete tools with no end in sight.

josteink 6y ago
> The problem is not "every obsolete .NET version", the problem is .net in reality have two incompatible platforms at this point, but newer C# versions are only supported on one of them. But that’s fairly consistent right? An old platform not getting updates and a new platform getting updates? Why would you expect the SDK of the officially deprecated platform to get updates with the latest compilers and technologies, but at the same time in every other way remain stagnant? Microsoft has been very clear that what you have will keep working, but you won’t get any new toys. If you want those, you have to put in the effort to upgrade your projects, and in worst case rewrite the portions you can’t. > So for the foreseeable future, .net will have these two platforms in parallel. Yeah. The old one not getting updated, used by those who won’t put in the effort to update their tools. And the new one where all the nice things are happening, which really should act as a nice carrot, not a source of bitterness. > Microsoft have forgotten how important developer enthusiasm is for the success of a platform. 99% of the old ASP.NET stack was terrible and unpleasant to work with. The new stuff is nice (enthusiastic!) to work with exactly because they decided to not carry all that stuff forwards. The new APIs was a nice fresh start for the current kind of apps one writes today.
- goto11 6y ago
  > But that’s fairly consistent right? An old platform not getting updates and a new platform getting updates? I'm not sure what you mean with "consistent", but the problem is of course creating two incompatible platforms in the first place. All previous releases of .net have been largely backwards compatible (except for rare edge cases and security issues), so it remained a single platform where you could get the latest improvement just by upgrading the framework. Of course when you have created two incompatible platforms, it would be double the work to keep both updated, so they have to abandon one. Which is why they shouldn't have done it in the first place. They could have upgraded and deprecated components in a modular manner without creating a whole separate incompatible platform.
  - josteink 6y ago
    > the problem is of course creating two incompatible platforms in the first place Interest in .NET was dwindling because ... it was Windows-only and its APIs and frameworks was a bad fit for the cloud. It was literally heading for a nose-dive. So if Microsoft wanted to address that and make .NET truly cross-platform, they either had 2 options: Port everything which is Windows-specific to all other platforms, or just strip it from the core .NET APIs. If they wanted to make it more cloud friendly, again they had 2 options: Make the already complex APIs, even more complex by trying to shoehorn cloud use-cases into a BCL largely designed for a Windows AD-network kind of security model. Or just start over, with a clean slate, and APIs designed for the age we're currently writing software for. While yes, the latter options creates a new incompatible platform, it's really the only realistic option. And if you're going for the first latter option, you might as well go for the second. I don't think you will find anyone who believes Microsoft would be able to execute on .NET Core as it did, if it had tried to bring all the old legacy along for the ride. > All previous releases of .net have been largely backwards compatible Yes. Which has been a mixed blessing. Look at what a mess classic ASP.Net has become (which ASP.NET MVC is built upon) wrt to page-event life-cycles and what not. Are you not happy to see all that terrible things truly gone, for good? > Which is why they shouldn't have done it in the first place. They could have upgraded and deprecated components in a modular manner without creating a whole separate incompatible platform. But that's what they did, really. They obsoleted classic ASP.NET and WebForms. They obsoleted WCF servers. And they obsoleted the Windows-centric security-model. Anything else? Everything else is still there. The language, the rest of the BCL, the packages you know and love. And you were given years after they said "These technologies are not getting any new updates" to migrate to the new ones (while still on classic .NET Framework), which was kindly published as multi-targeted Nuget-packages, to give you a gradual migration path. Sure. It wasn't perfect, but what is? If anyone is to blame here, it is how people have kept hanging on to classic .NET for years when the writing has been on the wall, hoping that maybe perhaps if they wait for another .NET Core release... That all those terrible technologies everyone is glad to let go off, will be ported to .NET Core too. You know what? It didn't happen, because .NET Core was a community project, and the community didn't want it, or at least certainly not enough to warrant the effort. And not only that! Thanks to being freed from the Windows it was borne into, it has become more vibrant and popular than ever before. It's no longer a technology threatened with extinction. As someone using and invested in .NET yourself, surely you must appreciate that?
torbica 6y ago
Exactly this. My current project is on full .NET Framework 4.8. It is on the latest possible version of ASP MVC, Entity Framework and all typical 3rd party libraries(of which 90% is supported on .NET 5). In the last two years we created several POCs for migration to .NET 5. Our current best estimate is 7 years for 80% of our development team. No sane manager will ever approve that crazy effort with almost no benefits for end users. Additionally we are talking here about most typical CRUD application without almost any advanced engineering. Our onboarding is taking at most 2 days and people can start be very productive even in first couple days. I can only imagine nightmares with more complex systems.