Swift on the Server (2020)(theswiftdev.com)
theswiftdev.com
Swift on the Server (2020)
https://theswiftdev.com/swift-on-the-server-in-2020/
106 comments
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-serve... I could probably add a half dozen more things.
I am now working with Kotlin and it's such a delight in comparison.
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-serve... I could probably add a half dozen more things.
I am now working with Kotlin and it's such a delight in comparison.
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.
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.
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
Does Apple use Swift (on Linux) for their own backend services?
How's GRPC support for Swift? That to me is more of a tell if anyone is using it for internal infrastructure and services in big companies.
It’s pretty good, maintained by an Apple engineer. https://github.com/grpc/grpc-swift
Not really. It’s mostly Java and Go.
Doesn't the iTunes and App Store backend still run on WebOjbects?
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.
How can you tell?
I worked there, and yes, most of the server side stuff is in Java and Go.
Disappointing but perhaps not surprising. Your experience is reasonably recent?
Do you need both or would just Go do :) ?
Hate Java
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.
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.
Either you ask someone who worked there, or you can trawl job postings.
Depends on the team, it’s a big company. There are definitely swift services internally.
They use a lot of Java and Scala. But I'm sure it's inevitable some teams are dogfooding Swift on the server as well. Swift is a very nice language.
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'd use Rust, Flask, Node, Go, Scheme, Elixir, or a variety of other platforms/approaches first.)
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.
my main concern would be google searches.
how do i do xyz in swift? results: "Taylor Swift is now dating small town midwest boy"
how do i do xyz in swift? results: "Taylor Swift is now dating small town midwest boy"
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.
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.
[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.
Try to use GNUStep to see how much an Apple language has managed to thrive outside of the ecosystem.
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.
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.
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.
The Swift Linux team might have 2-3 people. And knowing Apple, that might not be 100% of their time.
I've been paying attention to the GNUstep project periodically since 2004, and I can't recall Apple ever supporting the project.
I'm not sure that you can call this "thrive"
https://en.wikipedia.org/wiki/Category:Software_that_uses_GN...
https://en.wikipedia.org/wiki/Category:Software_that_uses_GN...
That’s what they are saying, it’s not thriving.
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.
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.
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 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!”
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.
> 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.
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.
:)
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...)
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.
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.
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.
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
if you're running brew on Linux, throw in the towel, it's over.
It does, but I’m not quite sure why you’d use it instead of apt or dnf or pacman...
[deleted]
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...
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?
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
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
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.
+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. 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.
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 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.
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.
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.
How did you find it? Was it worth the extra effort VS using some other language?
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.
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]
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.
And I love Objective C, but again, I only ever saw it being used for Mac and iOS.
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).
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.
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.
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 sweet spot you're looking for is Kotlin.
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).
More interesting things are Elixir and Julia, which arguably are in the similar sweet spot (Elixir may be closer to that than Julia).
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.
to be fair, Swift for Tensorflow was dropped (Feb 21) way after this article was written (Aug 20) https://github.com/tensorflow/swift
What does Swift have to do with Tensorflow. It's like comparing apples and oranges.
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/
Since then he has moved on to SiFive and S4TF has been shutdown. See HN discussion https://news.ycombinator.com/item?id=26117453
Since then he has moved on to SiFive and S4TF has been shutdown. See HN discussion https://news.ycombinator.com/item?id=26117453
He is still very active in Swift community though. The level of accessibility of key Swift contributors I can only compare to Elixir.
[deleted]
There was a port in the works at one point.
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.
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.
> Everything is async in Haskell, so you don’t need to think about it,
Then why does https://hackage.haskell.org/package/async exist?
Then why does https://hackage.haskell.org/package/async exist?
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.
Not sure if it's actually correct though.
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
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
I love Swift. It's my favourite language for application development. It's terrible that it's effectively restricted to Apple platforms.
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
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
Do you want to take a look at https://github.com/liuliu/s4nnc/ ? Nothing to serious though.
Thanks, that looks useful.
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?