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.
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.
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 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.
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 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!”
> 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!”
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.
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...)
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.
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.
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.
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.
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.
I've used Swift as the backend language for a side-project website around 2018-2019. I may be out of date, but I wouldn't recommend it. My main reasons:
1. The server-side frameworks are nascent and still changing – you will really be on the cutting edge if you use them, so be ready to deal with bugs and to change your project structure when the devs drop support for the old framework version.
2. Related to the above – not having a community around the frameworks means you'll have to figure a lot of stuff yourself – DB connection not working and throwing a weird error? You might not find that answer in SO.
3. It's a compiled language – so once you deploy, it can take up to 5+ minutes until the code is live; Swift (in iOS at least) doesn't have a good story around build times, so you're at the mercy of improvements in Swift development, probably coming from Apple (unless you get in the weeds and start setting up your own build chain)
4. Deployment – when I was working on the project, Heroku was the only platform that offered a stack for Swift, which they have since deprecated. I didn't feel like expending the effort to update to the new stack, and will probably re-write the backend. It's been a minute since last I worked with Swift, so maybe more platforms now offer (quick) Swift deployment.
It's a beautiful language and it has a lot of things going for it, but as far as server-side, I recommend sticking with boring technologies: RoR, Django, Node (which is what I'm using currently).
A lot has changed and Vapor Swift community is alive and has made significant improvements. The Swift build pack for Heroku works fine. I’ve deployed a cluster of Swift services in Kubernetes. No issues so far for side projects.
I love Swift. Especially the newer versions (swift 1 and 2 were so awful I gave up on it completely but 3+ are great).
But... I wouldn’t personally use it for anything other than iOS/Mac development because it’s always so hard to find examples / tutorials / help on stackoverflow for less-used languages and I imagine that’s what will be in store for me if I go this way.
This is unfortunately true. I just wrote a very simple little web service in Vapor.
Vapor itself is fantastic, but for documentation and examples, you’re pretty much limited to (1) the Vapor docs (2) the Vapor API docs buried on GitHub and (3) the source code. Fortunately the source itself is pretty well organized and easy to follow.
It’s hard for me to compare to other languages in this space, like Go or Rust, because I have basically no experience with them beyond the very most basic introductory toy projects. My choices came down to Python (with Flask or aiohttp) or Swift with Vapor.
There were a couple of weeks where I wished I had just gone with Flask and been done with it.
But beyond the short term, now that I have it working, I’m glad I went with Swift. One big plus is that I can reuse a bunch of Swift Codable types between my iOS app and the web app. Another is that I feel like I have a better performance/concurrency story than I’d get with Flask.
Edit to add: I don’t think getting started with Vapor was any harder than with aiohttp. And for me, it was a lot easier than learning a whole new language like Rust.
There are plenty of good reasons in the discussion already why server-side Swift might be a risky choice. I’ll add one more.
I like Swift. I’d like to use it more. Most of my work is either web backend or web frontend or both. My only Swift experience is from developing personal use Mac apps. But I do like the language.
[The biggest thing holding me back from even trying out a weekend project with server-side Swift is the fact that the only weekend project server-side work I have in mind is specifically oriented around improving on TypeScript/Node offerings.]
But the next reason after that is that Apple just isn’t invested in server platforms generally. This is similar but slightly different from the several comments about Apple not investing in other platforms.
Apple only tangentially invests any effort into Windows support to benefit the iOS/macOS platforms, true. But their only motivation to support Linux is gated by the extent to which they might want to focus on server products or cloud platform products in general.
They categorically don’t show much interest. Their own networked products use a hodgepodge of whatever was probably most convenient: some AWS, some Azure, some Google Cloud; a huge smattering of languages; some in house stuff, a lot not; a hilarious history of offering server hardware and letting it languish.
They want SwiftUI to be the future successor to the Cocoa APIs, and it’s been notoriously undocumented. What pain lies for people trying to use the language for use cases they actually don’t care about?
It's such a shame Swift has such abysmal support outside Apple, because it is a thousand times more beautiful and pleasing than Rust (while offering _some_ of the safeguard mechanisms).
For me there's a sweet spot that is meant for languages like Java, C# and now Swift.
For me at least Swift is the natural successor of this family of language for a bunch of reasons.
I would'nt create a program in C++ or Rust if i can do it in Swift, because its much more pleasant, productive and safer (while i love the level of control and speed C++ and Rust gives you).
I would just go for C++ or Rust if the domain i'm solving require this. Even because for some problem domains there are very few languages you can use. And i'm glad that now we have more options on this space like Rust and Zig.
But for business kind of languages, applications with common business logic, for me at least there's nothing better than Swift.
Script languages can be even better at ergonomics and productivity, but they tend to have a price that its only perceived later in regards to efficiency and the lack of a proper type system.
On the server side unfortunately, Swift is too late to the party and Go is already eating the Java cake. But i see a tremendous potential in Swift for user facing applications.
Both are in the same sweet spot. But both are big languages with a lot of features and requires a lot of support. Luckily, so far, they are supported by big companies (JetBrain is no Apple, but has a good track record of supporting this kind of things).
More interesting things are Elixir and Julia, which arguably are in the similar sweet spot (Elixir may be closer to that than Julia).
If you look on the Swift GitHub page you will see tremendous effort going into async/await. It will change the game for server side swift later this year.
this! lack of proper async support has been a big deterrent for me when considering Swift on my server or even Docker/CLI project. I worried that things like SwiftNIO/Vapor would change significantly when async landed and would require a lot of upkeep... I look forward to async landing.
I don’t know how Swift works, but from my Haskell experience, if your language needs async/await —- it’s already failing. Everything is async in Haskell, so you don’t need to think about it, and cannot accidentally make a mistake by blocking your async thread by calling sync code from it.
I think what he means is that everything in Haskell is "async" because the language runtime is lazy and types can encode parallelism: monads and functors fro sequential, blocking code, while applicatives for independent code.
Nothing to do with laziness. It just means you cannot accidentally call blocking (sync) operation from a lightweight (async) thread and block a whole bunch of other lightweight threads like in Rust, C#, or other languages with explicit “async” keyword
Swift is inherently tied to the Obj-C runtime and messaging system (and GCD), which is OLD (read: Darwin/NextStep). The Windows and Linux ports have large swathes of this low level infrastructure either missing or replaced with platform specific shims. This isn’t even to say anything of GUI toolkits etc.
Apple likely doesn’t use these ports of Swift for anything other than bragging rights to say it open sourced a thing.
GCD has been open sourced for a long time, but I’m not sure these concurrency primitives even work fully or as expected outside of an Apple OS with Swift. Hence Swift is essentially half baked abandonware on said platforms.
I love Swift, but it has no compelling use case out of Cupertino.
Swift is a great all purpose language. Before Google dropped the Swift TensorFlow project, I had started writing a “Swift AI” book. I bailed on the book, and instead have a live-book GitHub repo with code and README files for the various non-TensorFlow projects (which I tossed out to /dev/null). The live book is at https://github.com/mark-watson/Swift-AI-live-book-and-code
I just finished implementing a small service that talks to the stamps.com API and I have to say that its been really easy to implement. Deployment via Docker is really easy, for small services Vapor is just great. The Vapor Discord community is absolutely fenomenal.
I’m surprised the article didn’t mention Apple’s own swift HTTP server that builds on its NIO library. If I was going to write a Swift server I’d start with that.
This guy is in denial. Swift has been dropped by IBM and by Google for Tensorflow and Apple doesn't appear to be doing much to promote Swift outside of iOS and MacOS.
After leaving Apple, Chris Lattner (designer of Swift) ended up at Google for a while and there was an attempt to make Swift a first class language for Tensorflow. An interesting podcast on the topic from 2019: https://www.swiftbysundell.com/podcast/58/
Yes, but while web objects was a first class thing in the objective c world back in 1995 the direction swung due Java from about 1997 onwards — I doubt there’s any non-Java WOA any more. For example, it was developed when 32 bit PowerPC was a thing and I don’t think it ever made it to 64 bit Intel.
If you were starting from scratch, you probably would start with a different system. However web objects was their web framework at the time which was ported from objective c to java decades ago and shifting legacy from any technology to another is practically impossible especially if that technology is a cost rather than a product.
Swift on the server might make sense for an Apple-only full-stack developer, who wants to remain Apple-only, who is happy with the Swift development experience on the frontend, and who is willing to bet their backend on Apple's developer support.
(I'd use Rust, Flask, Node, Go, Scheme, Elixir, or a variety of other platforms/approaches first.)
I was looking for a language to dive deeper into, and I was going to pick between Swift or Rust. I ended up going with Rust. Why? I wanted something to replace C++ that I can write once and re use on Android or iOS. Also, I found lots of interesting projects where other people were using Rust. I don’t just jump the bandwagon, but I just didn’t see that much excitement for Swift or really understand it’s future as a general purpose language outside of Apple development.
And I love Objective C, but again, I only ever saw it being used for Mac and iOS.
for me personally main thing what is putting me off from Swiftlang is lack of namespaces (packages) :( all these workarounds with enums to provide some kind of namespacing look like workarounds rather than proper solutions how to organize bigger codebase.
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.