5 ms·

The upgrade path is massive rewrites, something most business are wary of. For good reasons. MS really made a grave mistake by coupling the evolution of the C#

by goto11 6y ago

The upgrade path is massive rewrites, something most business are wary of. For good reasons. MS really made a grave mistake by coupling the evolution of the C# language to the .NET version. This means all projects on the .NET framework is now also stuck with an obsolete language version for no good reason. It is becoming a a lot less fun to be a C# developer because you more often will have to work with obsolete tools.

nycdotnet 6y ago
At work we've been slowly pulling code out of our WebForms monolith. That's still on .NET Framework, and will be forever until we're done killing it, but we can use recent VS and MSBuild with it and we use C# 9 as well. Business code generally works copy and paste in .NET Core, so there's a really good path to migrate to newer stuff, especially with .Net Standard 2.0 being a thing. gRPC is really fast and we have the WebForms monolith call into .NET Core services now so we can improve the back-end without dealing with so much ASPX crap.
nikanj 6y ago
Your programming language either dies young, or it lives long enough to become the very legacy crud it sought to replace.
wvenable 6y ago
> MS really made a grave mistake by coupling the evolution of the C# language to the .NET version. For the most part that isn't true. You can use later C# compilers with older frameworks. Some features do, unavoidably, require framework support. But that being said, the changes in C# aren't often that radical that I feel particularly constrained by older versions.
- Mindless2112 6y ago
  You can (and I do), but it is explicitly not supported. If it breaks, you get to keep both halves.
nullsense 6y ago
>It is becoming a a lot less fun to be a C# developer because you more often will have to work with obsolete tools. This
josteink 6y ago
> 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.

by goto11 6y ago

nycdotnet 6y ago

At work we've been slowly pulling code out of our WebForms monolith. That's still on .NET Framework, and will be forever until we're done killing it, but we can use recent VS and MSBuild with it and we use C# 9 as well. Business code generally works copy and paste in .NET Core, so there's a really good path to migrate to newer stuff, especially with .Net Standard 2.0 being a thing. gRPC is really fast and we have the WebForms monolith call into .NET Core services now so we can improve the back-end without dealing with so much ASPX crap.

nikanj 6y ago

Your programming language either dies young, or it lives long enough to become the very legacy crud it sought to replace.

wvenable 6y ago

> MS really made a grave mistake by coupling the evolution of the C# language to the .NET version. For the most part that isn't true. You can use later C# compilers with older frameworks. Some features do, unavoidably, require framework support. But that being said, the changes in C# aren't often that radical that I feel particularly constrained by older versions.

Mindless2112 6y ago
You can (and I do), but it is explicitly not supported. If it breaks, you get to keep both halves.

nullsense 6y ago

>It is becoming a a lot less fun to be a C# developer because you more often will have to work with obsolete tools. This

josteink 6y ago

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