Swift is entering server-side Java’s territory
What the developer wants, the developer gets! A handful of Web Frameworks emerged after Swift became available on Linux, ignited by boosted interest in using Swift on the server. As a consequence, the Server APIs work group was formed with the goal “of making it possible for anyone to build a simple, secure, HTTP server, or to start to build other server frameworks like pub/sub message brokers.”
Chris Bailey, Runtime Development for Java, Node.js and Swift, Senior Technical Staff Member (STSM) at IBM, announced in late October the launch of the Server APIs work group which provides the framework for community members who are interested in building server applications and frameworks to work together on providing new Swift APIs. According to the announcement, “these APIs will provide low level ‘server’ functions as the basic building blocks for developing server-side capabilities, removing the reliance on interfacing with generally platform specific C libraries for these functions.” Developers will now be able to create frameworks and server applications using pure-Swift code (which means they don’t need to have systems programming skills and knowledge of multiple platforms).
What is the Server APIs project all about?
To become a better language for server-side development, this programming language needs great low-level APIs common among server frameworks. This project is meant to offer core capabilities in different areas including security and networking “so Swift programs no longer need to frequently rely on platform-specific C libraries to provide this functionality.”
The Server APIs will offer access to low-level, standards defined capabilities such as sockets, HTTP parsing and security, they will be cross-platform and work on platforms supported by Swift and will serve as a foundation to enable those frameworks to be developed by others.
The Server APIs project will initially focus on creating API proposals for HTTP parsing, security, base networking and encryption. One of the most important goals of Server APIs is to support the platforms that Swift is currently available on and be in a position to adopt new platforms as and when Swift support is added.
The Server APIs project is being managed as part of the Swift.org open source community. It is not yet tied to release along with any specific version of the Swift language, therefore the project can mature at its own pace as this programming language marches on toward version 4.
Swift 4: What to expect
Chris Lattner, a senior director of the Developer Tools Department at Apple, posted a note to the Swift mailing list four months ago in which he offered a sneak peek into what’s going to happen in Swift 4. According to the note, the main goals for Swift 4 are “to deliver on the promise of source stability from 3.0 on, and to provide ABI stability for the standard library.” Therefore, the team will be taking a two-stage approach the next year.
In stage 1, the development team will “focus on the essentials required for Source and ABI stability, and keep reasonably strict focus on only that work” —this means that features which do not radically “change the ABI of existing language features or imply an ABI-breaking change to the standard library will not be considered in this stage.” ABI details, resilience, and source stability features are among the goals for stage 1.
In stage 2, the team will scope and plan other large features depending on how much time they have left. Because it is virtually impossible to know now how the stage 2 timeframe will look like, Lattner revealed that the “laundry list of commonly requested features” includes generics improvements, .swiftmodule stability, property behaviors, new scripting features and more. “One specific thing to keep in mind is that Swift 3 isn’t done yet,” Lattner concluded.
The Swift team plans to ship Swift 3.x in Spring 2017 and Swift 4 in Fall 2017. There will also be some minor releases.