3 ms·

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 soft

by jitl 2y ago

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 2y ago
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 2y ago
  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-performance/ 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 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
Or containers. The Swift project is pretty good about keeping their Docker images up to date.

by jitl 2y ago

o11c 2y ago

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 2y ago
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-performance/ 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 2y ago
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 2y ago
  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 2y ago
    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 2y ago

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