-11
.NET and C# are in trouble. Here is what I'd do.
(www.youtube.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 01 Oct 2024
-11 points (21.1% liked)
C Sharp
1686 readers
4 users here now
A community about the C# programming language
Getting started
Useful resources
- C# documentation
- C# Language Reference
- C# Programming Guide
- C# Coding Conventions
- .NET Framework Reference Source Code
IDEs and code editors
- Visual Studio (Windows/Mac)
- Rider (Windows/Mac/Linux)
- Visual Studio Code (Windows/Mac/Linux)
Tools
Rules
- Rule 1: Follow Lemmy rules
- Rule 2: Be excellent to each other, no hostility towards users for any reason
- Rule 3: No spam of tools/companies/advertisements
Related communities
founded 2 years ago
MODERATORS
Sorry. Hadn't occurred to me you may not be able to see it (usually it's me who can't see things others post! ๐ ).
In a nutshell it boils down to the release schedule for .NET/C# - which people are paying to use - is too quick with too short support periods. He compares to another language, which is free (from memory I think it was Rust? I'd have to watch it again to see) which has the same short support periods, but is FREE. i.e. what are we paying for if we're not getting support for any longer than something which has the same support period for free? He's saying since MS is charging people for this, the support periods need to be longer, specifically security patches. e.g. if someone releases an app near the end of a period, then has only say 6 months before they have to upgrade it already, just to keep getting security patches. People don't have the option to stay on their stable release for a decent amount of time, even though they're paying for it. He just wants them to slow down the speed and increase the periods (we all know MS is all about pushing out new features over fixing bugs).
Theoretically one could simply upgrade to newer long term supported release when old one expires. Shouldn't break (a lot).
Yes, that's his point. That if you've released your app close to the end of the period, then you're forced to upgrade your app right away, even just to keep getting security patches, on top of any bugs you might already be trying to get on top of with your newly released app. Other systems have a longer support period and you wouldn't be faced with that.
If you look at LTS dates, 6 overlaps 8 by a year. And when it comes to patches, there are two scenarios. One is framework dependant app where you don't have to do anything. And there is self-contained where you have to update the app - but how else would you patch it - this is the same for every app out there, isn't it?