Apple is open sourcing Swift Build

And until packages are actually shipped for all mainstream distros, the stigma is completely accurate.

No, neither "just install a tarball" nor "just install this docker image" count.

Working on it: https://github.com/swiftlang/swiftly?tab=readme-ov-file

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.

I remember when all Linux projects used to be install a source tarball and do the configure, make config, make, make install dance.

That hasn't prevented Linux to take over most UNIX workloads.

Bringing synopsis here for those who may not click:

swiftly is a CLI tool for installing, managing, and switching between Swift toolchains, written in Swift. swiftly itself is designed to be extremely easy to install and get running, and its command interface is intended to be flexible while also being simple to use. The overall experience is inspired by and meant to feel reminiscent of the Rust toolchain manager rustup.

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.

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

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.

Go has been shipping for more than a decade as a .tgz and does not have this stigma at all ...

Anyway, you probably missed the following

https://www.swift.org/install/linux/

I see packages for all major distros there.

But people will probably mention some distro not listed and say the mainstream distro support is a farce. For some reason people have set the bar for Swift incredibly unrealistically high and there will always be something wrong it.

Your loss though. Swift is amazing. Both on MacOS and Linux.

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?

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.

If you actually click through, there is exactly one actual distro package there, and it is labeled "experimental". Everything else is exactly what I complained about - something that does not integrate into a real system.

That's not what I call "actually usable on non-Apple systems".

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.