Server-side Swift's slow support story sours some: Apple lang tailored for mobile CPUs, lacking in Linux world

Look what you made me

Analysis The Swift programming language has suffered some setbacks in its quest for ubiquity since Apple released it under an open-source license in 2015.

In December, IBM said it had reevaluated its priorities and decided to back away from server-side Swift development. Then last week, Vapor Cloud, a server-side Swift hosting biz, and a related service called Vapor Red, announced plans to shut down in February.

"Given that six years after Swift's release, even Swift Foundation on Linux is still incomplete, and expertise and documentation [remains] really sparse, I can certainly see how it's not an easy sell," observed developer Felix Schwarz via Twitter.

Many developers believe in Swift, citing its speed and efficiency, its memory safety, and its advantages as a full-stack language for iOS and macOS applications. But, particularly on Linux, Swift still has shortcomings, and some developers have been critical about missing pieces.

"We're running Swift on the server and I wish we didn't," remarked Pierpaolo Frasa, a developer at Chegg.com, in a post on the Swift community forum.

Acknowledging advantages like operator overloading, memory safety, its type system, and support for functional constructs, Frasa cited a variety of challenges facing those interested in working with server-side Swift: lack of Linux libraries; unresolved compiler bugs for Swift on Linux; lack of a good fault recovery option; lack of tooling, particularly on Linux, and a common build tool; and problems with modularity and compilation speed in big apps.

Big Blue's big blues

Yet while IBM's enthusiasm for server-side Swift has waned, there are companies running Swift of the backend aside from Apple, like Amazon. Server-side Swift isn't a lost cause. Rather it just needs to demonstrate proof-of-life.

In a phone interview with The Register, Sean Stephens, CEO of web design biz Treefrog, PerfectlySoft, and Lasso, expressed continued faith in the language and suggested Swift's path forward has more to do with public perception and community cohesion than technical issues.

PerfectlySoft makes a Swift server framework called Perfect, which evolved from Stephens's work with Lasso. It competes with similar projects like Vapor and IBM's Kitura.

Vapor has emerged the most popular of the projects but Stephens said his company has stepped away from marketing while continuing to develop Perfect and use it for its own projects.

"We did not feel welcomed by the Swift universe (on the contrary, we were/are pariahs), so we decided to focus on our own knitting," he explained.

To demonstrate Swift's viability on the backend, and the strengths of Perfect, PerfectlySoft and Canada's Centre of Excellence in Next Generation Networks last year conducted a benchmark test of various web frameworks and languages, including Spring, Perfect-NIO, Kitura, Node, Perfect-Net, Vapor, Go, Rails, Laravel, and Django.

Perfect-NIO came in behind Spring and Node but ahead of the other Swift frameworks and other languages.

Perfect-NIO-CENGN results

Five become one

As for why anyone might want to use Swift on the backend, Stephens cited its CPU efficiency, saying he's built projects with the expectation that five servers would be required where only one ended up being needed. He said he's told clients Swift has the potential to lower their cloud hosting bills by as much as 5x, or 10x even, if the application is CPU intensive.

Stephens said the Swift community's lack of focus on server-side Swift led to everyone doing their own thing and to political fractionalization. "At the end of the day, Vapor won the popularity vote," he said, "but it was built by people focused on the front-end rather than server-side.

He also pointed to the departure of Swift creator Chris Lattner, who left Apple in 2017 to head to Tesla and then Google, as a significant blow to the community. Interest in Swift, as measured by Stack Overflow queries, declined significantly after Lattner left the project. And he observed that Google's decision to embrace Kotlin rather than Swift for Android development hasn't helped.

"If Google had decided to adopt Swift for Android, then Swift would have eaten the world," he said.

Server-side Swift needs a high-profile user to demonstrate its capabilities, the way Shopify's e-commerce operation does for that Ruby on Rails, Stephens argued.

"If we had something like that, then people would wake up and take notice," he said. ®