Hacker News Reader

Comment by qalmakka | Hacker News Reader

It's 2021 and Swift is still nowhere to be found in the repositories of any of the Linux distributions I usually use. It's a big PITA to install, with nothing comparable to `rustup` or even truly universal prepackaged binaries - the official website only offers plain .tar.gzs for either Ubuntu LTS or CentOS, or source code. It's nowhere to be found on FreeBSD either, but there's a .exe for Windows.

Until they expect a novice to download and unpack random archives and set up environments without any kind of support they really can't expect to get any kind of growth on Linux. There's definitely no shortage of new, interesting languages, and too often Swift's support for non-Apple platforms feels more like an afterthought than anything.

View on HN

Swift had a chance 6-7 years ago when it first came out to capture mindshare on platforms other than iOS and macOS, but that chance was squandered. There's absolutely no reason someone would choose Swift over even .NET Core on other platforms these days. Thankfully, other languages have excelled during that timeframe.

[deleted]

Wikipedia disagrees: https://en.wikipedia.org/wiki/Swift_(programming_language)#V...

Just like Objective-C, it is a language for Apple platforms and that is about it.

Try to use GNUStep to see how much an Apple language has managed to thrive outside of the ecosystem.

I'm not sure that you can call this "thrive"

https://en.wikipedia.org/wiki/Category:Software_that_uses_GN...

That’s what they are saying, it’s not thriving.

Objective-C at least has Oolite as a cross-platform killer app to show off.

So much that I had to search for it.

Did Apple ever support GNUStep or make an attempt for ObjC to work on Linux in this millenium?

Because they do have people focused on maintaining Swift support for Linux. So it's a bit different.

I wonder what those people do all day, when they just Java and Go on server side, as per job offers.

When compared with Oracle, IBM, Microsoft and Google efforts for Linux support for their ecosystems, I really cannot see they work at all, given their output in the last five years.

I think they are understaffed. I know for Swift on Windows, there is exactly one person driving that effort last I checked.

The Swift Linux team might have 2-3 people. And knowing Apple, that might not be 100% of their time.

Which cleary shows how much that matters to Apple.

Well, my argument is that it matters more to them than Objective-C did.

I've been paying attention to the GNUstep project periodically since 2004, and I can't recall Apple ever supporting the project.

I had similar troubles trying to find the Swift ecosystem. The author's opening statement that Swift is everywhere rang hollow, even if it might be technically not strictly false when viewed from a certain angle under the right lighting conditions.

So, I'm playing with Rust.

Same. I love programming in Swift, but deploying it is a PITA. I got tired of waiting around for the cross-platform story to improve, so I moved on to Rust. It's refreshing to use tools which feel like they're made by someone who actually wants you to use them.

Swift is absolutely an afterthought on non-Apple platforms.

Apple doesn't even provide ARM slices for the official Swift Docker images (https://hub.docker.com/_/swift?tab=tags) which makes server-side development on their own cutting-edge M1 (ARM) machines basically impossible.

+1. For non-apple usage, I would want to see lot more GitHub repos with open source support for Swift. Right now even Kotlin/Rust and others beat Swift in that respect.

I really like the language, but I don’t know what is holding it back. I wish it solved concurrency without async/await keywords - that would have been a killer feature to compete with Go

> I really like the language, but I don’t know what is holding it back

From my limited outsider perspective, it seems like Apple's unwillingness to go out of their way to support Linux is what's holding it back. There seem to be a large number of people interested in using Swift on the server, but without first-party support, Swift on Linux will always be playing catch up, as new features will always land on MacOS first and often not be designed with any regard to how they'll work on Linux.

I am not sure which distros you use, but Swift is available in Fedora and EPEL (CentOS/RHEL) 8. The package name is swift-lang.

I can’t understand why you’re being downvoted. Unless, of course, the HN crowd doesn’t like anyone putting spikes into myths it likes to perpetuate, like “installing Swift is involved on Linux”.

Hello, it’s “dnf install -y swift-lang”, how less involved does it have to get?

“Burn the heretic! It’s involved! I’d rather curl | sudo bash things all day!”

> WesolyKubeczek

> I can’t understand why you’re being downvoted. Unless, of course, the HN crowd doesn’t like anyone putting spikes into myths it likes to perpetuate, like “installing Swift is involved on Linux”.

> Hello, it’s “dnf install -y swift-lang”, how less involved does it have to get?

> “Burn the heretic! It’s involved! I’d rather curl | sudo bash things all day!”

It seems like it's _officially_ packaged on only two distros which are relevant to Linux developers—Fedora, and NixOS https://repology.org/project/swift-lang/versions

It's also _unofficially_ packaged (aka by the community) for Arch via AUR, Slackware via SlackBuilds, and RHEL/CentOS via EPEL.

That's beyond pathetic, without even beginning to consider the resources of the company which backs them.

Take a look at how many distros Zig supports, for instance https://repology.org/project/zig/versions ...

...and Swift released the open-sourced Linux version roughly six years ago.

The problem with EPEL is that it's not supported by Redhat, and the packages that reside there are, for want of a better phrase, ephemeral. There are no guarantees.

If you're after a long term and well supported solution then EPEL probably isn't for you. And the same goes for Fedora, which I personally use, but wouldn't run in production for anything mission critical.

To be fair, the instructions on https://swift.org/download/#using-downloads are fairly straightforward and copy-pastable.

Indeed the prominence given to pgp signature verification is a breath of fresh air compared to the current wave of pipe-shell intros: it's not gatekeeping to ask a would-be programmer to exercise some reading skills and internalize the idea of signature verification.

What's the point of signature verification if you get the signature and the binary from the same server? I appreciate the lack of pretenses of `curl | sudo bash`.

Well, an attacker would need to first steal the private keys before they could generate the forged signatures.

So, while you could still change the public keys in the instructions and trick first-comers to install a back-doored archive, you'd still be caught in a heartbeat by everyone else who already trusted the legitimate keys (which are published via a keyserver.)

The chances and rewards of a successful, long-lasting attack are pretty slim, especially compared to those against other curl-bang installers (brew, oh-my-zsh...)

It kinda implies that no one writes Unix tools in swift, otherwise it would already be packaged in the disto of your choice

Yeah though I can see people not wanting to deploy a fat runtime just to run some cli tools.

Being able to install something is only half of the issue. I wouldnt touch a language for production where i have to setup my environment myself completely without package control.

I would hapily give it a try with a `brew install swift` but any involved install process is off putting.

Homebrew requires the Xcode command-line tools, which includes the Swift toolchain. If you have `brew`, you already have Swift.

Brew exists for Linux too

It does, but I’m not quite sure why you’d use it instead of apt or dnf or pacman...

brew lets you install packages without root/sudo.

Linux distributions don't depend on running random code from GitHub repositories like Homebrew does, it has package repositories. If those package repositories are compromised, Homebrew isn't going to save you, because you won't be able to trust your system at all at that point.

If you can't trust the software you're installing, it makes much more sense to run it in unprivileged containers or VMs than relying on account-level security. If a malicious package is distributed via Homebrew, it can still do a lot of damage running as your current user, as any data or resource accessible to your user can be exploited or exfiltrated.

I tend to agree with what another HN member wrote about sudo/root and Homebrew: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...

> Linux distributions don't depend on running random code from GitHub repositories like Homebrew does, it has package repositories.

Is the Homebrew github repo not a package repository?

Anyone can upload a Homebrew formula to Github that installs a malicious binary via brew.

Debian, for example, has trusted build systems that compile packages for their package repositories, and some packages already have reproducible builds[1].

Package repositories on Linux tend to provide the sources and binaries needed to install software. Homebrew just supplies formulas on GitHub, which only contain instructions on how to fetch and install externally hosted binaries, or instructions on how to fetch and install via externally hosted source code.

[1] https://wiki.debian.org/ReproducibleBuilds

Homebrew has build servers that compile pre-built binaries.[1] Most of the common software that people install with it (not considering Casks) comes in this form.

It’s not the case that anyone can upload a malicious formula, either. They do review requests to update formulas.

[1] https://docs.brew.sh/Bottles

There was a post today about their auto version upgrade PR bot. I don't think any distro does that.

That's not a benefit, and not how it should work.

if you're running brew on Linux, throw in the towel, it's over.

It's kinda ironic for such a closed company to try to create a multiplatform language.

I like to think that Kotlin captured all the hopes that people had for swift that were dashed, but as an Android dev that loves using the language I sometimes can't tell if anyone cares for my favorite language or not.

Reply on news.ycombinator.com