←back to thread

Apple is open sourcing Swift Build

(www.swift.org)
612 points dayanruben | 1 comments | 01 Feb 25 16:44 UTC | HN request time: 0s | source
Show context
sgt ◴[01 Feb 25 17:04 UTC] No.42899856[source]▶
Is Swift actually serious about embedded?
replies(6): >>42899910 #>>42899953 #>>42900093 #>>42900473 #>>42901728 #>>42905236 #
dlachausse ◴[01 Feb 25 17:13 UTC] No.42899953[source]▶
Yes, there was an entire WWDC ‘24 talk about it…

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.

replies(1): >>42899998 #
o11c ◴[01 Feb 25 17:17 UTC] No.42899998[source]▶
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.

replies(4): >>42900090 #>>42900144 #>>42900164 #>>42901385 #
jitl ◴[01 Feb 25 17:32 UTC] No.42900144[source]▶
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.

replies(2): >>42900266 #>>42900512 #
o11c ◴[01 Feb 25 17:44 UTC] No.42900266[source]▶
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.

replies(2): >>42900651 #>>42901732 #
1. jitl ◴[01 Feb 25 18:19 UTC] No.42900651[source]▶
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.