12 ms·

Swift on the Server (2020)

101 points by gozzoo 5y ago

qalmakka 5y ago
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.
- whatatita 5y ago
  I would hapily give it a try with a `brew install swift` but any involved install process is off putting.
  - NobodyNada 5y ago
    Homebrew requires the Xcode command-line tools, which includes the Swift toolchain. If you have `brew`, you already have Swift.
    - iddan 5y ago
      Brew exists for Linux too
      - jolux 5y ago
        It does, but I’m not quite sure why you’d use it instead of apt or dnf or pacman...
        deleted 5y ago
        [deleted]
        tgymnich 5y ago
        brew lets you install packages without root/sudo.
        heavyset_go 5y ago
        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-package-managers/#to-sudo-or-not-to-sudo https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
        rsa25519 5y ago
        > 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?
        heavyset_go 5y ago
        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 https://wiki.debian.org/ReproducibleBuilds
      - alrs 5y ago
        if you're running brew on Linux, throw in the towel, it's over.
- harikb 5y ago
  +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
  - saghm 5y ago
    > 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.
- pjmlp 5y ago
  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.
  - slezyr 5y ago
    I'm not sure that you can call this "thrive" https://en.wikipedia.org/wiki/Category:Software_that_uses_GNUstep https://en.wikipedia.org/wiki/Category:Software_that_uses_GN...
    - codetrotter 5y ago
      That’s what they are saying, it’s not thriving.
  - Apocryphon 5y ago
    Objective-C at least has Oolite as a cross-platform killer app to show off.
    - pjmlp 5y ago
      So much that I had to search for it.
  - raydev 5y ago
    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.
    - pjmlp 5y ago
      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.
- xbar 5y ago
  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.
  - skohan 5y ago
    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.
- heavyset_go 5y ago
  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.
  - blario 5y ago
    [deleted]
    - cygx 5y ago
      Wikipedia disagrees: https://en.wikipedia.org/wiki/Swift_(programming_language)#Version_history https://en.wikipedia.org/wiki/Swift_(programming_language)#V...
- eecc 5y ago
  To be fair, the instructions on https://swift.org/download/#using-downloads 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. :)
  - iudqnolq 5y ago
    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`.
    - eecc 5y ago
      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...)
  - GoOnThenDoTell 5y ago
    It kinda implies that no one writes Unix tools in swift, otherwise it would already be packaged in the disto of your choice
    - Redoubts 5y ago
      Yeah though I can see people not wanting to deploy a fat runtime just to run some cli tools.
  - herbst 5y ago
    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.
- H_L 5y ago
  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 https://hub.docker.com/_/swift?tab=tags) which makes server-side development on their own cutting-edge M1 (ARM) machines basically impossible.
- _-david-_ 5y ago
  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.
  - WesolyKubeczek 5y ago
    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!”
    - thegeekpirate 5y ago
      > 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 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 https://repology.org/project/zig/versions ... ...and Swift released the open-sourced Linux version roughly six years ago.
  - teh_klev 5y 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.
- Larrikin 5y ago
  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.
- arthur_sav 5y ago
  It's kinda ironic for such a closed company to try to create a multiplatform language.
jonplackett 5y ago
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.
- cvwright 5y ago
  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.
  - jonplackett 5y ago
    How did you find it? Was it worth the extra effort VS using some other language?
    - cvwright 5y ago
      Overall I found it pretty nice. 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.
- deleted 5y ago
  [deleted]
GoOnThenDoTell 5y ago
Does Apple use Swift (on Linux) for their own backend services?
- yakkityyak 5y ago
  Not really. It’s mostly Java and Go.
  - Longhanks 5y ago
    How can you tell?
    - alblue 5y ago
      I worked there, and yes, most of the server side stuff is in Java and Go.
      - qaq 5y ago
        Do you need both or would just Go do :) ? Hate Java
        alblue 5y ago
        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.
        qaq 5y ago
        I am not sure what is upsetting about the question was honestly wondering how realistic it is to work at Apple on services using primarily Go.
      - bartvk 5y ago
        Disappointing but perhaps not surprising. Your experience is reasonably recent?
tracer4201 5y ago
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.
sentinel 5y ago
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).
- gjs278 5y ago
  this is a list of all the shittiest backend languages in one post
- pixel_tracing 5y ago
  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.
  - sentinel 5y ago
    Glad to hear about the improvements! Swift is a great language, I hope to someday get back to using it.
  - 5y ago
singularity2001 5y ago
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).
- oscargrouch 5y ago
  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.
  - The_rationalist 5y ago
    The sweet spot you're looking for is Kotlin.
    - liuliu 5y ago
      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).
cutler 5y ago
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.
- slver 5y ago
  What does Swift have to do with Tensorflow. It's like comparing apples and oranges.
  - programmarchy 5y ago
    There was a port in the works at one point.
  - agsnu 5y ago
    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/ https://www.swiftbysundell.com/podcast/58/ Since then he has moved on to SiFive and S4TF has been shutdown. See HN discussion https://news.ycombinator.com/item?id=26117453 https://news.ycombinator.com/item?id=26117453
    - qaq 5y ago
      He is still very active in Swift community though. The level of accessibility of key Swift contributors I can only compare to Elixir.
      - deleted 5y ago
        [deleted]
- elpakal 5y ago
  to be fair, Swift for Tensorflow was dropped (Feb 21) way after this article was written (Aug 20) https://github.com/tensorflow/swift https://github.com/tensorflow/swift
AndrewZM 5y ago
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.
rnantes 5y ago
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.
- k_bx 5y ago
  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.
  - nextaccountic 5y ago
    > Everything is async in Haskell, so you don’t need to think about it, Then why does https://hackage.haskell.org/package/async https://hackage.haskell.org/package/async exist?
    - eecc 5y ago
      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. Not sure if it's actually correct though.
      - k_bx 5y ago
        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
    - k_bx 5y ago
      Please keep in mind it’s a library, not a language extension. It exists same reason any other library exists. It’s a useful set of combinators
- 5y ago
spideymans 5y ago
I love Swift. It's my favourite language for application development. It's terrible that it's effectively restricted to Apple platforms.
mark_l_watson 5y ago
Nice, thanks for writing that up! 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 https://github.com/mark-watson/Swift-AI-live-book-and-code
- liuliu 5y ago
  Do you want to take a look at https://github.com/liuliu/s4nnc/ https://github.com/liuliu/s4nnc/ ? Nothing to serious though.
  - mark_l_watson 5y ago
    Thanks, that looks useful.
neilv 5y ago
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.)
danschumann 5y ago
my main concern would be google searches. how do i do xyz in swift? results: "Taylor Swift is now dating small town midwest boy"
- bartvk 5y ago
  That is barely a concern. Do you feel the same for Go, or Rust, or Bash?
  - danschumann 5y ago
    Yea.
johnthuss 5y ago
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. https://github.com/apple/swift-nio-http2 https://github.com/apple/swift-nio-http2
eyelidlessness 5y ago
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?
akoncius 5y ago
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.
Tainnor 5y ago
My team and I ran a rather complex backend application written in Swift for several years in production. There are nice things about the language, but so many things are missing, poorly supported or just extremely annoying. A teammate wrote a summary of the myriad issues we had: https://forums.swift.org/t/issues-learned-4-years-with-server-side-swift/35115 https://forums.swift.org/t/issues-learned-4-years-with-serve... I could probably add a half dozen more things. I am now working with Kotlin and it's such a delight in comparison.
cortexio 5y ago
``` Swift is as easy to use as a scripting language, without sacrificing any performance. This means C-like performance in most of the cases, which should be more than enough for most of the people. ``` Uggh, even PHP webservers are more performant than swift... I dont even understand how they can be that slow. >_< Also "Swift is everywhere" and "Swift is a modern, interactive, type-safe programming language with performance in mind. It is one of the fastest growing programming languages in the industry" Is one big fat lie. What an article...
chrismsimpson 5y ago
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.

101 points by gozzoo 5y ago

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.

whatatita 5y ago
I would hapily give it a try with a `brew install swift` but any involved install process is off putting.
- NobodyNada 5y ago
  Homebrew requires the Xcode command-line tools, which includes the Swift toolchain. If you have `brew`, you already have Swift.
  - iddan 5y ago
    Brew exists for Linux too
    - jolux 5y ago
      It does, but I’m not quite sure why you’d use it instead of apt or dnf or pacman...
      - deleted 5y ago
        [deleted]
      - tgymnich 5y ago
        brew lets you install packages without root/sudo.
        heavyset_go 5y ago
        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-package-managers/#to-sudo-or-not-to-sudo https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
        rsa25519 5y ago
        > 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?
        heavyset_go 5y ago
        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 https://wiki.debian.org/ReproducibleBuilds
    - alrs 5y ago
      if you're running brew on Linux, throw in the towel, it's over.
harikb 5y ago
+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
- saghm 5y ago
  > 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.
pjmlp 5y ago
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.
- slezyr 5y ago
  I'm not sure that you can call this "thrive" https://en.wikipedia.org/wiki/Category:Software_that_uses_GNUstep https://en.wikipedia.org/wiki/Category:Software_that_uses_GN...
  - codetrotter 5y ago
    That’s what they are saying, it’s not thriving.
- Apocryphon 5y ago
  Objective-C at least has Oolite as a cross-platform killer app to show off.
  - pjmlp 5y ago
    So much that I had to search for it.
- raydev 5y ago
  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.
  - pjmlp 5y ago
    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.
xbar 5y ago
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.
- skohan 5y ago
  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.
heavyset_go 5y ago
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.
- blario 5y ago
  [deleted]
  - cygx 5y ago
    Wikipedia disagrees: https://en.wikipedia.org/wiki/Swift_(programming_language)#Version_history https://en.wikipedia.org/wiki/Swift_(programming_language)#V...
eecc 5y ago
To be fair, the instructions on https://swift.org/download/#using-downloads 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. :)
- iudqnolq 5y ago
  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`.
  - eecc 5y ago
    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...)
- GoOnThenDoTell 5y ago
  It kinda implies that no one writes Unix tools in swift, otherwise it would already be packaged in the disto of your choice
  - Redoubts 5y ago
    Yeah though I can see people not wanting to deploy a fat runtime just to run some cli tools.
- herbst 5y ago
  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.
H_L 5y ago
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 https://hub.docker.com/_/swift?tab=tags) which makes server-side development on their own cutting-edge M1 (ARM) machines basically impossible.
_-david-_ 5y ago
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.
- WesolyKubeczek 5y ago
  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!”
  - thegeekpirate 5y ago
    > 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 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 https://repology.org/project/zig/versions ... ...and Swift released the open-sourced Linux version roughly six years ago.
- teh_klev 5y 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.
Larrikin 5y ago
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.
arthur_sav 5y ago
It's kinda ironic for such a closed company to try to create a multiplatform language.

jonplackett 5y ago

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.

cvwright 5y ago
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.
- jonplackett 5y ago
  How did you find it? Was it worth the extra effort VS using some other language?
  - cvwright 5y ago
    Overall I found it pretty nice. 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.
deleted 5y ago
[deleted]

GoOnThenDoTell 5y ago

Does Apple use Swift (on Linux) for their own backend services?

yakkityyak 5y ago
Not really. It’s mostly Java and Go.
- Longhanks 5y ago
  How can you tell?
  - alblue 5y ago
    I worked there, and yes, most of the server side stuff is in Java and Go.
    - qaq 5y ago
      Do you need both or would just Go do :) ? Hate Java
      - alblue 5y ago
        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.
      - qaq 5y ago
        I am not sure what is upsetting about the question was honestly wondering how realistic it is to work at Apple on services using primarily Go.
    - bartvk 5y ago
      Disappointing but perhaps not surprising. Your experience is reasonably recent?

tracer4201 5y ago

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.

sentinel 5y ago

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).

gjs278 5y ago
this is a list of all the shittiest backend languages in one post
pixel_tracing 5y ago
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.
- sentinel 5y ago
  Glad to hear about the improvements! Swift is a great language, I hope to someday get back to using it.
- 5y ago

singularity2001 5y ago

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).

oscargrouch 5y ago
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.
- The_rationalist 5y ago
  The sweet spot you're looking for is Kotlin.
  - liuliu 5y ago
    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).

cutler 5y ago

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.

slver 5y ago
What does Swift have to do with Tensorflow. It's like comparing apples and oranges.
- programmarchy 5y ago
  There was a port in the works at one point.
- agsnu 5y ago
  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/ https://www.swiftbysundell.com/podcast/58/ Since then he has moved on to SiFive and S4TF has been shutdown. See HN discussion https://news.ycombinator.com/item?id=26117453 https://news.ycombinator.com/item?id=26117453
  - qaq 5y ago
    He is still very active in Swift community though. The level of accessibility of key Swift contributors I can only compare to Elixir.
    - deleted 5y ago
      [deleted]
elpakal 5y ago
to be fair, Swift for Tensorflow was dropped (Feb 21) way after this article was written (Aug 20) https://github.com/tensorflow/swift https://github.com/tensorflow/swift

AndrewZM 5y ago

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.

rnantes 5y ago

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.

k_bx 5y ago
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.
- nextaccountic 5y ago
  > Everything is async in Haskell, so you don’t need to think about it, Then why does https://hackage.haskell.org/package/async https://hackage.haskell.org/package/async exist?
  - eecc 5y ago
    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. Not sure if it's actually correct though.
    - k_bx 5y ago
      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
  - k_bx 5y ago
    Please keep in mind it’s a library, not a language extension. It exists same reason any other library exists. It’s a useful set of combinators
5y ago

spideymans 5y ago

I love Swift. It's my favourite language for application development. It's terrible that it's effectively restricted to Apple platforms.

mark_l_watson 5y ago

Nice, thanks for writing that up! 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 https://github.com/mark-watson/Swift-AI-live-book-and-code

liuliu 5y ago
Do you want to take a look at https://github.com/liuliu/s4nnc/ https://github.com/liuliu/s4nnc/ ? Nothing to serious though.
- mark_l_watson 5y ago
  Thanks, that looks useful.

neilv 5y ago

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.)

danschumann 5y ago

my main concern would be google searches. how do i do xyz in swift? results: "Taylor Swift is now dating small town midwest boy"

bartvk 5y ago
That is barely a concern. Do you feel the same for Go, or Rust, or Bash?
- danschumann 5y ago
  Yea.

johnthuss 5y ago

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. https://github.com/apple/swift-nio-http2 https://github.com/apple/swift-nio-http2

eyelidlessness 5y ago

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?

akoncius 5y ago

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.

Tainnor 5y ago

My team and I ran a rather complex backend application written in Swift for several years in production. There are nice things about the language, but so many things are missing, poorly supported or just extremely annoying. A teammate wrote a summary of the myriad issues we had: https://forums.swift.org/t/issues-learned-4-years-with-server-side-swift/35115 https://forums.swift.org/t/issues-learned-4-years-with-serve... I could probably add a half dozen more things. I am now working with Kotlin and it's such a delight in comparison.

cortexio 5y ago

``` Swift is as easy to use as a scripting language, without sacrificing any performance. This means C-like performance in most of the cases, which should be more than enough for most of the people. ``` Uggh, even PHP webservers are more performant than swift... I dont even understand how they can be that slow. >_< Also "Swift is everywhere" and "Swift is a modern, interactive, type-safe programming language with performance in mind. It is one of the fastest growing programming languages in the industry" Is one big fat lie. What an article...

chrismsimpson 5y ago

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.