←back to thread

612 points dayanruben | 5 comments | | HN request time: 0.216s | source
Show context
sgt ◴[] No.42899856[source]
Is Swift actually serious about embedded?
replies(6): >>42899910 #>>42899953 #>>42900093 #>>42900473 #>>42901728 #>>42905236 #
dlachausse ◴[] 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 ◴[] 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 ◴[] 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 #
1. o11c ◴[] 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 #
2. jitl ◴[] 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.

3. AlotOfReading ◴[] No.42901732[source]
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?
replies(1): >>42903175 #
4. o11c ◴[] No.42903175[source]
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.

replies(1): >>42903775 #
5. AlotOfReading ◴[] No.42903775{3}[source]
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.