[jitl]

Distro packaging for programming language ecosystems is so often hopelessly out of date. I’ve never used a distro toolchain or packages to build production software for any language Python’s age or younger.

Outside of C/C++/Fortran pretty much every project I see on Github prefers things like Rustup or Nix for toolchains to navigate around Debian/Ubuntu/RHEL’s “stability” approach.

[o11c]

I disagree vehemently. For any active language, distro packages should be at most 3 years old.

And for any language that's stable enough to be worth using, "3 years old" is good enough.

[jitl]

Python, Java, C#, JavaScript, Go, Ruby all improve so substantially in 3 years time, I can’t square the advantages of using a distro package for any of them versus using at least the latest LTS from upstream. What is so great about the distro package versus upstream, that it is worth being 2-3 years behind?

Mostly I hear “stability”, but I have encountered far more frustrations dealing with 3 year old software as a developer, than I ever have dealing with 6 month old software. If I have good test coverage, a way to deterministically reproduce my build environment, reliable CI, and a way to release packages and bugfixes to my users quickly, it seems the risk & blast radius of a 6 month old toolchain is quite limited.

Python is by some measures the most popular programming language, its first release was in 1991, and over the last 3 years performance improved significantly, see https://lost.co.nz/articles/sixteen-years-of-python-performa...

I imagine the only case I want an ancient toolchain is if I’m building libraries or software predominantly consumed by Debian stable or RHEL users / system package ecosystem, or I am doing some kind of high-assurance thing involving formal verification where I’m probably using a non-distro verified toolchain instead. I’ve never been too interested in either of those domains though.

[AlotOfReading]

Both GCC and Clang have shipped support for major updates to C and C++ within the last 3 years. If C and C++ aren't stable enough, what is?

[o11c]

And is there any actual need to use those right now? No.

I lived through the C++11 transition (which was the only actually significant improvement C++ has ever had), and as much as GCC 4.6 was enticing, it really wasn't a burden to keep supporting GCC 4.4 in stable software. Only for ground-breaking development (which takes long enough to stabilize that stable distros will have the new GCC) is it worth starting to use the new features unconditionally.

Now, C++ does have a much better source-level compatibility story than most languages (e.g. `#if ... #define constexpr /* compiler too old */`), but that just means that newer languages have no excuse for refusing to learn from its successes.

[AlotOfReading]

I just picked a random, notable feature (std::format) and the LTS my systems are currently on (22.04). The current Clang in universe is 14, which doesn't have a complete std::format implementation. That's one of the most popular features from a 5 year old language standard that many people are using today and yet it's still not available on a common LTS version without adding the LLVM repos.

[cvwright]

Or containers. The Swift project is pretty good about keeping their Docker images up to date.