7 ms·

One thing I appreciate about C# and .NET is how well they resist codebase rot. In some other languages, I often encounter situations where the development envir

One thing I appreciate about C# and .NET is how well they resist codebase rot. In some other languages, I often encounter situations where the development environment needs to be completely recreated—sometimes due to an updated interpreter version or other breaking changes. If you've been away from the codebase for a while, chances are you'll need to make modifications just to get it running in a more recent environment. With .NET, this issue is much less pronounced. While occasional adjustments are necessary, the environment is largely self-contained, minimizing the overhead required to get things running. As long as the .NET SDK is installed, running dotnet restore is usually all it takes—even when moving the codebase to an entirely new machine. Some third-party libraries evolve more rapidly than others, but the core .NET libraries remain remarkably stable. More often than not, you can transition between major versions without needing to modify any code. If I were starting a long-term project that required ongoing maintenance, C# would be my top choice. For quick scripting needs, I’d lean toward Python or PowerShell. In fact, PowerShell itself is another reason I appreciate .NET—it shares many concepts, and knowing .NET makes it easier to understand PowerShell. Plus, since PowerShell can directly leverage .NET libraries, it offers powerful scripting capabilities. I was thrilled when PowerShell became cross-platform, much like .NET itself.

whoknowsidont 2y ago
>With .NET, this issue is much less pronounced. This is because Windows comes with some form of .NET, but also other programs end up needing to install multiple versions of the .NET runtime. Eventually, you just have them on your machine. It's the equivalent to installing every version of Python and just letting the problem sort itself out. It's not different than other tech-stacks, you're just eating the costs up front instead of running into them in a more obvious manner. .NET (in its entirety) has lots of breaking changes that won't work from one version to another. More recently MS has been better about documenting these, especially as .NET's footprint increases inside outside of the control of MS (non-Windows environments): https://learn.microsoft.com/en-us/dotnet/core/compatibility/breaking-changes https://learn.microsoft.com/en-us/dotnet/core/compatibility/... >In fact, PowerShell itself is another reason I appreciate .NET it shares many concepts PowerShell is built on .NET (in whatever form .NET Framework and .NET/core) lol. It doesn't "share" anything, it _IS_ shell for .NET.
- unsignedint 2y ago
  Yes, but in the case of Python, I feel it's a bit more nuanced. Simply having Python installed isn't enough—you also have to manage virtual environments (venv, Poetry, or whatever is popular at the moment). Personally, I find this to be more of an ongoing maintenance burden. I do acknowledge that .NET has its share of breaking changes from time to time, but in my experience, the friction is significantly lower compared to other environments I’ve worked with. > PowerShell is built on .NET (in whatever form .NET Framework and .NET/core) lol. It doesn't "share" anything, it _IS_ shell for .NET. I never said it wasn’t! I was simply speaking from the perspective of the frontend experience. While PowerShell is built on .NET, my point was about how its functionality and design make it feel familiar to those already accustomed to .NET development.
  - whoknowsidont 2y ago
    >my point was about how its functionality and design make it feel familiar to those already accustomed to .NET development. Because it's literally a "shell" into the .NET runtime/framework. PowerShell _extensively_ uses reflection capabilities. My point was they're not sharing some design philosophy or converging, PowerShell is just exposing .NET functionality directly and in an interactive manner. You in fact, can write a pretty similar tool with a few lines of C# that makes use of dynamic compilation and reflection. Otherwise, PowerShell shares nothing (and I mean nothing) with other .NET languages (C#, F#, etc). It's history and design choices come from things like KornShell and Perl. Where do you think all those $variables and "-ne" operators came from?
    - unsignedint 2y ago
      Look, I’m not disagreeing with you here. I’m not even talking about the internal mechanics—I’m simply referring to the user experience. You're fixating on my choice of words and taking my point in a direction I never intended. All I’m saying is that knowing .NET makes it easier to write PowerShell scripts, and I appreciate that. If that’s not your experience, that’s fine—but that doesn’t change my perspective.
- 2y ago
billfruit 2y ago
The same is even better with Java. It's common to find Java binaries build 20 Years+ to run on present day systems without issue.
- mgh95 2y ago
  From what I gather, the only time this occurred was very early in the C#/.NET ecosystem (.NET2) when generics were added in November 2005. So it should be at 20 years this year. Both languages are very impressive and benefit from the competition.
  - cyberax 2y ago
    Early C# often depended on libraries that were MS-specific, partially native code, and are often no longer even available. This changed around 2014-ish, as a result C# has been really stable for a decade.
    - mgh95 2y ago
      Possibly. I'm a relatively recent comer to the c# ecosystem (2021ish). It's been good and avoids some of the warts of java. Really, though, I'm very happy there is competition in the GC enterprise languages for linux. Regardless of who is "better", the competition will continue to drive progress in this area.
    - eterm 2y ago
      .NET framework is still supported, you can target "net48" instead of net8.0 in your project build targets.
      - lostmsu 2y ago
        Some C# features don't work in that mode though.
        brewmarche 2y ago
        You can opt into most of them by setting LangVersion manually to your preferred C# version. It works since most new C# features are just syntactic sugar which is lowered by the compiler. Some of them require new types in the BCL (e.g. Range/Index, marker types for required/init/records), but for that you can just reference PolySharp which will generate the missing types on the fly. Features that will not work typically also need runtime support, so default interface methods, static interfaces and the like will not work.
Kwpolska 2y ago
Upgrades between modern .NET (Core) versions are simple and painless. It’s just a single-character change in the .csproj file, plus maybe upgrading some dependencies (but old versions will usually work). Upgrading from the classic .NET Framework to the modern .NET is usually a long process. Simple console apps, desktop apps, and libraries might be doable with an automated csproj upgrade. But Web apps require a rewrite from scratch, because the old ASP.NET is incompatible with the modern ASP.NET Core.
- pipes 2y ago
  This hasn't been the case for me at all, the jumps between lts releases have burnt a lot of my time figuring out how to fix broken things. Though c# is definitely my favourite language to work in :)
  - jbluepolarbear 2y ago
    What difficulties did you experience? I’ve upgraded many projects from ancient C# v2 and more modern versions. There are always some things that need to be addressed, but as long as you look at the changes from the one version to the next it’s easy enough to figure out what needs to be changed. Most modern IDEs will point out the issues in an upgrade report.
    - pipes 2y ago
      Bit hazy now, but at work every time an LTS change happens the first team to do it publishes it's notes on how it fixed various issues. Off the top of my head I remember a problem with swagger, but to be fair that's a third party lib. Problems with other 3rd party libraries with version mismatches (i.e one dependency wanting one version and another wanting a different one). It's not some major gripe, just it has never been smooth sailing! :)
- Clubber 2y ago
  >It’s just a single-character change in the .csproj file When .NET 10 comes out, it will be 2 characters, double the work of the previous process. Unacceptable! /s
sandreas 2y ago
What I really like is the fact that you can basically build anything in this language. From command line tools over Apps or small GUIs up to full fledged Server Backends or Webservices, even WASM... everything is possible. The NativeAOT approach is also very interesting making it possible to build native binaries similar in size and performance to languages like Rust and Go (not quite actually, but close). It's also possible to build "single binary" tools by using <PublishSingleFile> which comes in handy when building small helper tools for the command line.
mattgreenrocks 2y ago
This is going to sound really unfair, but compared to some of the more hip languages, the .NET/JVM ecosystems feel a bit more like they have adults at the helm who at least try to maintain backward compat. They’re also stodgy as hell sometimes, but I’ll take that. There’s a real difference in culture that manifests in both what is made and what is held up as good engineering. And that has an effect of raising the bar on what is acceptable from an ecosystem POV. Yes, it’s possible you’ll have to deal with Enterprise-y code sometimes. But, it’s usually your team’s choice as to what is written. Also, people don’t seem to complain quite as much about it when they encounter it at a FAANG elsewhere that tries to do “good” engineering, but that’s another discussion. :)
- CharlieDigital 2y ago
  > They’re also stodgy as hell sometimes, but I’ll take that. Can't speak for Java, but C# has been evolving very rapidly and for the better with each iteration. I feel like the C# team really focuses on DX when evaluating language features. Best place to get a feel for how rapidly the language evolves for the better is the version release docs for C#: C# 13: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-13 https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... C# 12: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-12 https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... C# 11: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-11 https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... etc. Compared to JS, Go, Java, etc. I feel like C# evolves significantly faster and the team is faster to validate, implement, and deliver improvements to the language. I think this is also why some folks who tried C# say 5-6 years ago have no idea how fast the language has evolved for the better.
- fsloth 2y ago
  "This is going to sound really unfair, " That's not unfair at all, I think it's a fair assessment. Industrial tools should have adults at the helm. People who care about longevity and robustness foremost. About delivering quality and stability where the main value points of a language are.
- fortran77 2y ago
scarface_74 2y ago
> One thing I appreciate about C# and .NET is how well they resist codebase rot. During the time I was working with .net from 2005-2020, I saw the transition from Webforms to ASP.NET MVC to the MVC/WebAPI split. I also saw the transition from Linq2SQL to Entity Framework. There was also the weird time when you could run ASP.Net Core and EF Core on top of .Net Framework. Then the entire .Net Framework to .Net Core was a major upheaval.
- oaiey 2y ago
  It was necessary and worth it.
brainzap 2y ago
to only downside, If you support everything, everything will be used. Deprecating aggressive hurts shortterm but pays off long term.
amelius 2y ago
Microsoft is king of backward compatibility.

whoknowsidont 2y ago

>With .NET, this issue is much less pronounced. This is because Windows comes with some form of .NET, but also other programs end up needing to install multiple versions of the .NET runtime. Eventually, you just have them on your machine. It's the equivalent to installing every version of Python and just letting the problem sort itself out. It's not different than other tech-stacks, you're just eating the costs up front instead of running into them in a more obvious manner. .NET (in its entirety) has lots of breaking changes that won't work from one version to another. More recently MS has been better about documenting these, especially as .NET's footprint increases inside outside of the control of MS (non-Windows environments): https://learn.microsoft.com/en-us/dotnet/core/compatibility/breaking-changes https://learn.microsoft.com/en-us/dotnet/core/compatibility/... >In fact, PowerShell itself is another reason I appreciate .NET it shares many concepts PowerShell is built on .NET (in whatever form .NET Framework and .NET/core) lol. It doesn't "share" anything, it _IS_ shell for .NET.

unsignedint 2y ago
Yes, but in the case of Python, I feel it's a bit more nuanced. Simply having Python installed isn't enough—you also have to manage virtual environments (venv, Poetry, or whatever is popular at the moment). Personally, I find this to be more of an ongoing maintenance burden. I do acknowledge that .NET has its share of breaking changes from time to time, but in my experience, the friction is significantly lower compared to other environments I’ve worked with. > PowerShell is built on .NET (in whatever form .NET Framework and .NET/core) lol. It doesn't "share" anything, it _IS_ shell for .NET. I never said it wasn’t! I was simply speaking from the perspective of the frontend experience. While PowerShell is built on .NET, my point was about how its functionality and design make it feel familiar to those already accustomed to .NET development.
- whoknowsidont 2y ago
  >my point was about how its functionality and design make it feel familiar to those already accustomed to .NET development. Because it's literally a "shell" into the .NET runtime/framework. PowerShell _extensively_ uses reflection capabilities. My point was they're not sharing some design philosophy or converging, PowerShell is just exposing .NET functionality directly and in an interactive manner. You in fact, can write a pretty similar tool with a few lines of C# that makes use of dynamic compilation and reflection. Otherwise, PowerShell shares nothing (and I mean nothing) with other .NET languages (C#, F#, etc). It's history and design choices come from things like KornShell and Perl. Where do you think all those $variables and "-ne" operators came from?
  - unsignedint 2y ago
    Look, I’m not disagreeing with you here. I’m not even talking about the internal mechanics—I’m simply referring to the user experience. You're fixating on my choice of words and taking my point in a direction I never intended. All I’m saying is that knowing .NET makes it easier to write PowerShell scripts, and I appreciate that. If that’s not your experience, that’s fine—but that doesn’t change my perspective.
2y ago

billfruit 2y ago

The same is even better with Java. It's common to find Java binaries build 20 Years+ to run on present day systems without issue.

mgh95 2y ago
From what I gather, the only time this occurred was very early in the C#/.NET ecosystem (.NET2) when generics were added in November 2005. So it should be at 20 years this year. Both languages are very impressive and benefit from the competition.
- cyberax 2y ago
  Early C# often depended on libraries that were MS-specific, partially native code, and are often no longer even available. This changed around 2014-ish, as a result C# has been really stable for a decade.
  - mgh95 2y ago
    Possibly. I'm a relatively recent comer to the c# ecosystem (2021ish). It's been good and avoids some of the warts of java. Really, though, I'm very happy there is competition in the GC enterprise languages for linux. Regardless of who is "better", the competition will continue to drive progress in this area.
  - eterm 2y ago
    .NET framework is still supported, you can target "net48" instead of net8.0 in your project build targets.
    - lostmsu 2y ago
      Some C# features don't work in that mode though.
      - brewmarche 2y ago
        You can opt into most of them by setting LangVersion manually to your preferred C# version. It works since most new C# features are just syntactic sugar which is lowered by the compiler. Some of them require new types in the BCL (e.g. Range/Index, marker types for required/init/records), but for that you can just reference PolySharp which will generate the missing types on the fly. Features that will not work typically also need runtime support, so default interface methods, static interfaces and the like will not work.

Kwpolska 2y ago

Upgrades between modern .NET (Core) versions are simple and painless. It’s just a single-character change in the .csproj file, plus maybe upgrading some dependencies (but old versions will usually work). Upgrading from the classic .NET Framework to the modern .NET is usually a long process. Simple console apps, desktop apps, and libraries might be doable with an automated csproj upgrade. But Web apps require a rewrite from scratch, because the old ASP.NET is incompatible with the modern ASP.NET Core.

pipes 2y ago
This hasn't been the case for me at all, the jumps between lts releases have burnt a lot of my time figuring out how to fix broken things. Though c# is definitely my favourite language to work in :)
- jbluepolarbear 2y ago
  What difficulties did you experience? I’ve upgraded many projects from ancient C# v2 and more modern versions. There are always some things that need to be addressed, but as long as you look at the changes from the one version to the next it’s easy enough to figure out what needs to be changed. Most modern IDEs will point out the issues in an upgrade report.
  - pipes 2y ago
    Bit hazy now, but at work every time an LTS change happens the first team to do it publishes it's notes on how it fixed various issues. Off the top of my head I remember a problem with swagger, but to be fair that's a third party lib. Problems with other 3rd party libraries with version mismatches (i.e one dependency wanting one version and another wanting a different one). It's not some major gripe, just it has never been smooth sailing! :)
Clubber 2y ago
>It’s just a single-character change in the .csproj file When .NET 10 comes out, it will be 2 characters, double the work of the previous process. Unacceptable! /s

sandreas 2y ago

What I really like is the fact that you can basically build anything in this language. From command line tools over Apps or small GUIs up to full fledged Server Backends or Webservices, even WASM... everything is possible. The NativeAOT approach is also very interesting making it possible to build native binaries similar in size and performance to languages like Rust and Go (not quite actually, but close). It's also possible to build "single binary" tools by using <PublishSingleFile> which comes in handy when building small helper tools for the command line.

mattgreenrocks 2y ago

This is going to sound really unfair, but compared to some of the more hip languages, the .NET/JVM ecosystems feel a bit more like they have adults at the helm who at least try to maintain backward compat. They’re also stodgy as hell sometimes, but I’ll take that. There’s a real difference in culture that manifests in both what is made and what is held up as good engineering. And that has an effect of raising the bar on what is acceptable from an ecosystem POV. Yes, it’s possible you’ll have to deal with Enterprise-y code sometimes. But, it’s usually your team’s choice as to what is written. Also, people don’t seem to complain quite as much about it when they encounter it at a FAANG elsewhere that tries to do “good” engineering, but that’s another discussion. :)

CharlieDigital 2y ago
> They’re also stodgy as hell sometimes, but I’ll take that. Can't speak for Java, but C# has been evolving very rapidly and for the better with each iteration. I feel like the C# team really focuses on DX when evaluating language features. Best place to get a feel for how rapidly the language evolves for the better is the version release docs for C#: C# 13: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-13 https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... C# 12: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-12 https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... C# 11: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-11 https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... etc. Compared to JS, Go, Java, etc. I feel like C# evolves significantly faster and the team is faster to validate, implement, and deliver improvements to the language. I think this is also why some folks who tried C# say 5-6 years ago have no idea how fast the language has evolved for the better.
fsloth 2y ago
"This is going to sound really unfair, " That's not unfair at all, I think it's a fair assessment. Industrial tools should have adults at the helm. People who care about longevity and robustness foremost. About delivering quality and stability where the main value points of a language are.
fortran77 2y ago

scarface_74 2y ago

> One thing I appreciate about C# and .NET is how well they resist codebase rot. During the time I was working with .net from 2005-2020, I saw the transition from Webforms to ASP.NET MVC to the MVC/WebAPI split. I also saw the transition from Linq2SQL to Entity Framework. There was also the weird time when you could run ASP.Net Core and EF Core on top of .Net Framework. Then the entire .Net Framework to .Net Core was a major upheaval.

oaiey 2y ago
It was necessary and worth it.

brainzap 2y ago

to only downside, If you support everything, everything will be used. Deprecating aggressive hurts shortterm but pays off long term.

amelius 2y ago

Microsoft is king of backward compatibility.