The Future of Swift on the Server

Swift on the server

This is a post I've been meaning to write for a very long time. I'm conscious that I'm completely biased when it comes to this topic. I have a large amount of potentially misplaced optimism and a vested interest in seeing Swift on the server succeed. But I also believe that I have more insight than most given I work full-time on it. I'm also expecting to generate a lot of, uh, discussion with this post - so hey Twitter, Reddit and Hacker News 👋

I first thought about writing something when coming back from the ServerSide.swift conference. For those who haven't heard of it (and full disclosure, I'm one of the organisers) ServerSide.swift is an international conference for Swift on the Server (no surprises there). It's the one place where everyone from the community can come together because of the focus on the server. It's a great place to find very technical talks like gRPC and testing NIO systems. It was an awesome conference, an amazing line up of speakers and there was a real buzz around the community. Having recently quit my 'proper' job to work on server-side Swift full time, I was feeling pretty pleased with it all!

IBM and Kitura

Then a month later, IBM quietly announced they were stepping away from Swift as one of their open source languages. It was a huge blow for the community, especially everyone who was using Kitura and invested in it. Added to that, the way that IBM made no formal announcement left a bad taste for many.

It was a real shame to see IBM exit the Swift on the server scene. Competition is always good, and IBM should be remembered for the amount of work they put in to make server-side Swift viable. After the announcement, there were lots of people and articles taking this as the sign that Swift on the server is dead. After all, if IBM can't make it work, why would anyone use it?

2020 - The year of the server

To be clear, I'm not saying that everything was (and is) perfect when using Swift on the server. There are teething problems and issues arising from its immaturity. Developing on Linux, crash handling, lack of OS support, debugging, SwiftPM features - all have provided bumps in the road and issues. And up until quite recently, if you didn't want to get your hands dirty so to speak, I wouldn't have recommended using Swift on the server.

However, since January there have been major developments that show real promise for the future. First, towards the end of January, Ted Kremenek posted On the road to Swift 6 on the forums. And rather than being the Swift 6 roadmap, this was essentially the Swift on the server roadmap. Every single goal of Swift 6 is either related to the server or has a direct benefit for it. Things like new OS support, LSP improvements, build times and dependency management improvements. The list goes on, and I haven't even mentioned the aim for a real concurrency model, which for me is the last missing piece for Swift on the server.

To signify the importance of all this, the Swift core team got two new members. Tom Doron - who is responsible for SwiftNIO and the Swift Server Work Group - and Saleem Abdulrasool - who almost single-handedly has dragged Swift onto Windows. Having both on the core team signify the importance of Swift outside the Apple ecosystem to the Swift team.

Then, a few days later, Mishal Shah posted on the forums to announce that there would be nightly Docker images available for Swift. While this doesn't affect most developers, it is important. It allows you to test changes in Swift and Foundation without having to either compile Swift or install a new toolchain. So framework developers can now test code against pre-release versions of Swift without much effort.

It also builds on the monthly releases of Swift for Linux that have been happening for over a year now. Originally started with Swift 4.2.2, it opened the way for getting fixes for Foundation quickly rather than waiting for the next Xcode release. And amazingly, this was a case of Linux getting quicker Swift releases than macOS!

A week after the nightly Docker images announcement, Cory Benfield went on stage at dotSwift to announce the release of Swift Crypto. Crypto is a part of any server ecosystem that you really want to have. Rolling your own Crypto is a bad idea and linking against OpenSSL was causing issues. It was difficult to integrate with OpenSSL from all the different operating systems. And relying on the system-provided OpenSSL would stop Swift from supporting HTTP/2 and HTTP/3 in any reasonable timeframe.

Swift Crypto still isn't without its issues, which is to be expected. Currently Swift Crypto doesn't support either RSA keys or PEM/DER keys. This is problematic in the server world for 95% of use cases! 😅 The current workaround is to embed your own copy of BoringSSL and use that yourself. (And also every dependency that needs these features to embed their own copy of BoringSSL.) Again this is due to Swift's immaturity and something that the Swift Crypto team will fix going forward.

But the good news kept coming. Earlier this month the Google Summer of Code projects for Swift were announced on the forums. Out of the four projects announced, two were directly working on improvements for server-side and Linux.

Then finally, the next day Tom Doron announced support for more Linux distributions. This is a huge step forward for Swift because it makes it easier to run Swift on the OS you're already using. Lots of companies have infrastructure and tooling built around different OSes. By constraining Swift to Ubuntu only (Docker aside), it meant these companies couldn't use it. Now they can and with support for Amazon Linux, it even opens up opportunities for things like Lambda.

To coincide with the announcement (whether by coincidence or not), Amazon release 2.0 of their Smoke Framework. It's really cool to see a company like Amazon go all in with Swift on the server. And if you want to learn more about it, check out Simon's video from ServerSide.swift:

Not just the server

Whilst everything above is great news for the server, there are non-server use cases that are starting to make inroads. The biggest is Swift for Tensorflow. Using Swift for machine learning may seem like an odd choice, and Google choosing Swift as one of their primary ML languages even odder! But there are good reasons why it was chosen. Tryolabs recently did a deep-dive into the reasons, background and benefits of this and it's a great read! And even though this may not be applicable to you (it certainly isn't to me!) it provides two big benefits.

The first is improving the language itself. The S4TF team needed to make some big changes to both Swift and the compiler to allow things like differentiable programming and Python/C++ interoperability. We're now seeing these changes being merged back upstream into Swift itself, where they can be used by anyone. Additionally, the S4TF team recently released Swift Benchmark to benchmark code. It's awesome to see great tooling for Swift developed outside of Apple!

Second, it provides a big mindshare opportunity. A major project using and evolving Swift outside of the Apple ecosystem is important. It proves to outsiders that Swift isn't 'the Apple language' and proves that the core team want Swift to be more than just the language to write iOS apps in.

There's also a large amount of work going on making Swift work on the web, but client side. The SwiftWasm project allows you write Swift and use it in the browser with WebAssembly. This could potentially mean writing Swift instead of JavaScript for websites 🎉 Although it's early days and a lot of work needs to be upstreamed back into Swift, it shows real promise and you can try it out now!

Looking forward

Things are moving quickly with server-side Swift and this year is only accelerating. I suspect we'll see more supported Linux distros and further improvements to the language. Though I don't expect Swift 6 and async/await to land this year. The release of Vapor 4 is another step forward and encompasses a lot of the work of the SSWG. The SSWG are also publishing a number of guides on best practices for building, deployment and debugging. These are definitely worth checking out.

It's important to remember that Swift is still young. It was only open sourced at the end of 2015. Go is a 'new' language, but it was first released in 2009. Rust, another language that's generating a lot of buzz first appeared in 2010. Swift is playing catch-up and you should take that into account when making comparisons. Whatever happens it's going to be an interesting year for Swift on the server. The future is definitely bright!