5 ms·

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.
- pjmlp 2y ago
  There were more breaking milestones, .NET to WinRT 8, WinRT 8 to UAP 8.1, UAP to UWP, UWP to WinUI 3/WinAppSDK,.NET Framework to .NET Core, Silverlight, XNA, Managed DirectX. All of those are also part of .NET ecosystem. Agree with the competition remark, hence why my toolbox has been .NET, Java, JavaScript ecosystems on the first drawer for decades now.
  - mgh95 2y ago
    Possible. I know little more than what I can google about .NETs history; I wasn't around for it. What I can say (MS hesitance aside) is that it is excellent for web applications where the ability to sustainably bear complexity of business logic is critical to business success. I only really saw that concern in the java ecosystem, and I am very happy .NET exists, if for no other reason than to force java to get better. Many ancillary tools (source generators, xml code generation, integration of compliance metrics) that are only ever found in java are already present and even better in the .NET world.
porcoda 2y ago
Yup! I recently took a pretty substantial project I wrote in 2006 in Java that was sitting in a tar file, unpacked it, and it ran just fine with a current JVM. Even better, I was able to compile it again with no problems: again, with a modern JDK. I wish I could say the same for years of projects written in Rust and Haskell: the Haskell ones are almost all bit rotten since I haven’t kept them up to date with GHC, and Rust is similar. Those two are even worse since with Java I had a rich standard library, so I didn’t have any 3rd party dependencies in my 19 year old project. The Haskell and Rust ones rely on Hackage and crates, and keeping things working for that long would require me to do bonus work beyond my actual project code. I’ve had similar but less painful problems in Python land: the library APIs are mostly stable: the biggest headache there are projects that predate python3 so there’s some work to bring them up to date. That’s at least a one time investment. Java: no bonus work induced by third parties to keep projects alive, keeps working for a long time. Would recommend.
- tome 2y ago
  > the Haskell ones are almost all bit rotten since I haven’t kept them up to date with GHC FWIW, over the last couple of years the stability story has got hugely better, thanks largely to the efforts of the Haskell Foundation Stability Working Group. You can see the breakage inventories that I've produced for the last few GHC releases, and see that the amount of breaking changes is decreasing rapidly: https://github.com/tomjaguarpaw/tilapia/ https://github.com/tomjaguarpaw/tilapia/
  - mattgreenrocks 2y ago
    Between compile times and HLS feeling fragile in VSCode, I’m pretty much done with Haskell at this point. Very nice language, just not my thing anymore.
    - tome 2y ago
      That's fair enough. Both of those are indeed week points of the ecosystem.
- 2y ago
merb 2y ago
this is definitly not true anymore, when the java libs used jaxb/xml/javaee stuff. most often because of java 9. its possible to make them running but its definitly not without issues. I did run so many 10 years old java binaries it was NEVER without issues.
sixothree 2y ago
The number of times I’ve had to install an older version of Java just to compile some code is not even remotely funny to me. I really hate this idea that you can have code that just won’t compile if you are using a modern environment.

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.
pjmlp 2y ago
There were more breaking milestones, .NET to WinRT 8, WinRT 8 to UAP 8.1, UAP to UWP, UWP to WinUI 3/WinAppSDK,.NET Framework to .NET Core, Silverlight, XNA, Managed DirectX. All of those are also part of .NET ecosystem. Agree with the competition remark, hence why my toolbox has been .NET, Java, JavaScript ecosystems on the first drawer for decades now.
- mgh95 2y ago
  Possible. I know little more than what I can google about .NETs history; I wasn't around for it. What I can say (MS hesitance aside) is that it is excellent for web applications where the ability to sustainably bear complexity of business logic is critical to business success. I only really saw that concern in the java ecosystem, and I am very happy .NET exists, if for no other reason than to force java to get better. Many ancillary tools (source generators, xml code generation, integration of compliance metrics) that are only ever found in java are already present and even better in the .NET world.

porcoda 2y ago

Yup! I recently took a pretty substantial project I wrote in 2006 in Java that was sitting in a tar file, unpacked it, and it ran just fine with a current JVM. Even better, I was able to compile it again with no problems: again, with a modern JDK. I wish I could say the same for years of projects written in Rust and Haskell: the Haskell ones are almost all bit rotten since I haven’t kept them up to date with GHC, and Rust is similar. Those two are even worse since with Java I had a rich standard library, so I didn’t have any 3rd party dependencies in my 19 year old project. The Haskell and Rust ones rely on Hackage and crates, and keeping things working for that long would require me to do bonus work beyond my actual project code. I’ve had similar but less painful problems in Python land: the library APIs are mostly stable: the biggest headache there are projects that predate python3 so there’s some work to bring them up to date. That’s at least a one time investment. Java: no bonus work induced by third parties to keep projects alive, keeps working for a long time. Would recommend.

tome 2y ago
> the Haskell ones are almost all bit rotten since I haven’t kept them up to date with GHC FWIW, over the last couple of years the stability story has got hugely better, thanks largely to the efforts of the Haskell Foundation Stability Working Group. You can see the breakage inventories that I've produced for the last few GHC releases, and see that the amount of breaking changes is decreasing rapidly: https://github.com/tomjaguarpaw/tilapia/ https://github.com/tomjaguarpaw/tilapia/
- mattgreenrocks 2y ago
  Between compile times and HLS feeling fragile in VSCode, I’m pretty much done with Haskell at this point. Very nice language, just not my thing anymore.
  - tome 2y ago
    That's fair enough. Both of those are indeed week points of the ecosystem.
2y ago

merb 2y ago

this is definitly not true anymore, when the java libs used jaxb/xml/javaee stuff. most often because of java 9. its possible to make them running but its definitly not without issues. I did run so many 10 years old java binaries it was NEVER without issues.

sixothree 2y ago

The number of times I’ve had to install an older version of Java just to compile some code is not even remotely funny to me. I really hate this idea that you can have code that just won’t compile if you are using a modern environment.