BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News IBM Stops Work on Swift — Q&A with Chris Bailey

IBM Stops Work on Swift — Q&A with Chris Bailey

This item in japanese

Bookmarks

IBM has recently discontinued its involvement in Server-side Swift development, which started soon after Swift was open-sourced, and relinquished its leadership in the Swift Server Work Group [SSWG]. InfoQ has talked to IBM's Chris Bailey to learn more about what this may imply for Swift and the Swift community.

The announcement, that went public on Swift's mailing list last month, sparked immediate reactions (1 and 2) in the Swift and broader developer community. Comments ranged across a rather large set of conjectures and diverse ideas about what IBM's announcement may actually mean for Server-side Swift development and what led IBM to such a decision.

Some developers hinted at Vapor, a competing framework to Kitura, IBM's framework for server-side Swift development, gaining more traction and making Kitura a less compelling choice. Others pointed at competitor languages such as Rust and Go as being more successful than Swift on the server. Some went so far as to suggest this could be the end of the Swift-on-the-server story. For each argument, some kind of counter-argument could be thought. Twitter offered a similar landscape.

To clarify how things really stand, InfoQ has taken the chance to speak with Chris Bailey, former senior technical staff member working on runtime technologies for Swift, and one of the two IBM contributors who left the Swift Server Work Group, along with Ian Partridge.

InfoQ: Could you describe your past involvement with the Server-side Swift project? What were your main contributions to the project?

Chris Bailey: Myself and the wider IBM team have been involved in the open source Swift.org project since it was announced. In the early days that was primarily making the core Swift language and APIs a viable option on Linux and in server environments. This included working on the Swift language itself, the Dispatch concurrency library, and the Foundation API library all of which form the Swift runtime. We also launched the Swift Server Work Group (SSWG) to bring together the various community groups working on server frameworks to collaborate on a common set of core libraries and expanding the server ecosystem.

Outside of the Swift.org community, we also created the Kitura framework and an ecosystem of libraries and tools around it to provide a complete microservices framework, with everything needed to run cloud-native applications.

InfoQ: Kitura is a well-established framework, with over 70 contributors and 163 releases over the years. Do you think it remains a great option for developers wishing to use Swift even after Ian Partridge and you have left the project?

Bailey: Kitura has thousands of downloads each day, and a number of large enterprises are using it in production — some of whom have talked publicly about how they are using it.

IBM is still supporting Kitura through any existing commercial agreements, but we're reducing our contributions to onward development of new features. This provides more space and opportunity for the wider community to engage — and we’re working to enable interested parties from the community to pick up this technology. Like any open source project, its long term success is dependent on there being an active community around it, and one where users are also willing to contribute to the technologies that they consume.

The hope is that this will make Kitura a more community led project and that it will continue to flourish.

InfoQ: What is the status of Swift for Linux? What needs to be done in your opinion to make it a competitive player for that platform?

Bailey: Swift is a great technology and one that stands firmly on the shoulders of giants — as a new language it has been designed and built fully in the knowledge of what has gone before and has adopted some of the best aspects of other languages.

It also has good fundamental characteristics for use on the server. Its heritage and focus on being used for mobile devices also means that it has a low memory footprint and benefits from fast startup - both of which are also valuable when running on servers.

The big question has always been whether it can cross the chasm from being something that iOS mobile developers use to build a full-stack backend for frontend (BFF) for their mobile apps, to a general purpose server technology used for a wider set of use cases.

Swift benefits greatly from being an embedded part of Apple's ecosystem, but it also provides challenges for its organic growth as there's a lot of dependency on Apple for capabilities that the server ecosystem requires. For example, almost all Swift developers use Apple's Xcode as their IDE and it has fantastic support for developing iOS devices, including the ability to run locally in emulator environments. It would be great to add support for writing server code that allows developers to develop directly into containerized environments from their local IDE by supporting the simple integration into Xcode of development tools such as Appsody. Where there is open governance and open ecosystems, it enables the community to contribute and to solve the problems and use cases that are important to them.

Apple is working hard to address these issues, to make Swift more open, and to help build the server ecosystem — and this has recently stared to pick up pace. Tom Doron has been a driving force from Apple in promoting the server ecosystem through the Swift Server Work Group and leading Apple's efforts in the server space. Additionally Ted Kremenek has recently posted On the road to Swift 6, which describes a strong statement of intent on steps to expand the ecosystem and make it more open — including driving more focus around the fledgling Language Server Protocol (LSP) project, which will enable other IDEs to better support Swift development.

InfoQ: Since Server-side Swift and Kitura were launched, the server-side, native language arena has seen the rise of Go and Rust. Rust especially seems to be a direct competitor to Swift, at least in terms of its focus on safety-first. How do you see those languages stack up against each other?

Bailey: Go, Rust and Swift are often grouped together as "Modern Native Languages" being type-safe, compiled, native languages which are seen as modern replacements for C and C++.

In terms of programming languages, Swift is very young. It first appeared in mid 2014, but its first release as an open source project with official support for Linux didn't occur until September 2016 — making it only 3.5 years ago. By contrast, Go is just over 10 years old and Rust is 9.5 years old. This means they've both had a significant head start.

Go has found a real niche as a systems language being used for the core infrastructure of cloud technologies like Kubernetes, as well as for developing CLIs. Rust is still finding its niche to a certain extent, but there's lots of interest being driven by Web Assembly. Swift is obviously a little further behind in the adoption curve.

At last years' AltConf, I presented a Server-Side Swift State of the Union which discussed the current level of adoption of server-side Swift. One of the things that I showed was a comparison of the size of the package ecosystem for Swift against Node.js at the same age — whilst Swift is behind where Node.js was at the same age, it's nowhere near as far behind as you might expect.

Fundamentally, Swift on the server has a lot of potential, and it would be fantastic to see that potential convert into success and wide-scale adoption.

You can follow the evolution of Server-side Swift on its official forum. InfoQ will continue to bring any significant story concerning it to its audience.

Rate this Article

Adoption
Style

BT