It’s happening
Ever since Swift was open sourced by Apple including a release for Linux, people speculated about why Apple would do this. The most popular theory was that Apple itself wanted to use Swift on the server. And these days, even for Apple — server equals Linux — hence the Linux release. As far as we know, much of Apple’s server infrastructure (at least the stores) is build on WebObjects — a technology that is showing its age (to put it mildly). Swift, as a language fully under Apple’s control, could be an obvious foundation for replacing WebObjects within Apple.
But until yesterday there was no server story from Cupertino at all, so the community stepped in:
Diversity is good, but some standardization in the community doesn’t hurt.
Luckily, there’s now going to be an official Server APIs project as part of Swift.org:
Swift has amazing potential on the server, and to be an even better language for server-side development Swift needs great low-level APIs common among server frameworks. The Server APIs project will provide core capabilities in areas such as networking and security so Swift programs no longer need to frequently rely on platform-specific C libraries to provide this functionality. As a result, developers will be able to create frameworks and server applications using pure-Swift code, without the need to also have systems programming skills and knowledge of multiple platforms
My take
I played with Swift and read its spec. It’s a nice language. Especially if you’re coming from Objective-C, it’s a huge leap forward.
The question is — does a leap forward compared to Objective-C make it and interesting enough language to develop servers in, compared to the dozens of established alternatives? Or is the primary audience for it iOS Swift developers that can then do full-stack Swift development?
Of what I’ve seen of Swift, it’s a very nice, but not a simple language. I know Apple is pushing it as a “my first programming language” for education (with Swift Playgrounds on iPad) — it has good reasons to do so, but is it as simple as a language can be? No, because a certain amount of cruft needed to be introduced to make it interact seamlessly with “legacy” Cocoa and Objective-C code. And of course, that additional complexity is of zero help on the server.
Is that a big deal? I don’t know.
To be successful on the server, a ginormous amount of work is going to be required to bring the Swift server ecosystem up to par with its competition — Java, Ruby, Python, PHP, Node, Go, and even Rust.
There is already good support for Swift (through Objective-C) for many things, but much of it won’t work on the server, because of dependencies on Cocoa and the Objective-C runtime. As a result it’s actually pretty hard to find libraries today you can use with Swift on the server. IBM has a catalog. What’s up with IBM’s obsession with Swift by the way.
What will Swift’s edge be?
But even if the ecosystem matures, what would be the win of Swift over its alternatives?
As I see it — this is what makes it interesting for server development:
- It compiles to native, highly optimized code and doesn’t require a VM to run — so it’s fast and cheap in terms of memory usage.
- If you’re an iOS/Mac developer that already uses Swift for your iOS/Mac apps — you get to use the same language (although likely with different libraries) on the server and client. Full-stack Swift!
- It’s a modern language, and has many modern features like type inference, option types, automatic memory management (without a garbage collector), generic programming, string interpolation, functions as first-class objects, solid unicode support, etc.
However…
What I’m missing is a compelling concurrency story.
We live in post thread-per-request world. Node.js is fully asynchronous and can handle thousands of concurrent requests easily, Go has channels and go-routines multiplexing multiple go-routines on a thread. Rust is close to the OS so only supports threads, but it can actually statically verify that no race conditions and other concurrency bugs can occur. Which is pretty wild.
So what’s Swift’s story here? At a language level it has none for now. Is Grand Central Dispatch a competitive answer on the server?
I’d say “no.”
There are some user-land libraries emerging that implement things like co-routines and channels in Swift, like Venice and Safe — but these things typically don’t interact well with existing “synchronous” APIs. There’s much to be said to have language (VM) level support (or at least strong conventions, like Node) for this thing these days (like Go and Erlang have).
But anyway, Swift on server is getting enough excitement to become a real thing. Let’s see if it will pick up outside the world of Apple believers.
