Try to use GNUStep to see how much an Apple language has managed to thrive outside of the ecosystem.
Because they do have people focused on maintaining Swift support for Linux. So it's a bit different.
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.
The Swift Linux team might have 2-3 people. And knowing Apple, that might not be 100% of their time.
https://en.wikipedia.org/wiki/Category:Software_that_uses_GN...
So, I'm playing with Rust.
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.
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
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.
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!”
> 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.
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.
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.
:)
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...)
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...
Is the Homebrew github repo not a package repository?
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.
It’s not the case that anyone can upload a malicious formula, either. They do review requests to update formulas.
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.