4 ms·

Yes, there was an entire WWDC ‘24 talk about it… https://developer.apple.com/videos/play/wwdc2024/10197 https://developer.apple.com/videos/play/wwdc2024/10197

by _mlbt 2y ago

Yes, there was an entire WWDC ‘24 talk about it… https://developer.apple.com/videos/play/wwdc2024/10197 https://developer.apple.com/videos/play/wwdc2024/10197 Swift is a great language, but it is unfortunately still held back by the stigma of being perceived as only usable on Apple platforms.

o11c 2y ago
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.
- timsneath 2y ago
  Working on it: https://github.com/swiftlang/swiftly?tab=readme-ov-file https://github.com/swiftlang/swiftly?tab=readme-ov-file
  - Terretta 2y ago
    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.
- 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.
- pjmlp 2y ago
  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.
- st3fan 2y ago
  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/ 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.
  - o11c 2y ago
    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".

by _mlbt 2y ago

o11c 2y ago

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.

timsneath 2y ago
Working on it: https://github.com/swiftlang/swiftly?tab=readme-ov-file https://github.com/swiftlang/swiftly?tab=readme-ov-file
- Terretta 2y ago
  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.
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.
pjmlp 2y ago
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.
st3fan 2y ago
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/ 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.
- o11c 2y ago
  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".