As soon as Swift was open-sourced, IBM created a Swift developer section on their developerWorks site, having been working with Swift on OSX for over a year and a half by that point. IBM also launched Swift on the server with a web-based REPL for Swift running on Linux, as covered by InfoQ previously. Since then, IBM engineers have been contributing to the port of Swift to Linux, including porting libdispatch to provide a multi-threaded runtime similar to the parallelism library on OSX.
IBM have since created the Swift package catalogue, providing a way to see what Swift packages are popular and to provide a seed for the future Swift package manager. This also provides a rating system, similar to GitHub's stars, for finding popular Swift related packages. At the moment Alamofire, a networking utliity package, is currently the most popular package. Alamofire was a Swift port of the existing Objective-C AFNetworking framework. Other notable packages include RxSwift, SwiftyJson, and the Kitura web framework. There's even a SwiftyGPIO package for interacting with Raspberry Pi input and output pins, for the unofficial Swift port for the Raspberry Pi.
Now that Swift 2.2 has been officially released on both OSX and Linux, including open-source contributions from a collection of non-Apple developers, it is likely that Swift will take off. Patrick Bohrer and Chris Bailey presented at QCon London 2016 on Swift on the Server, and spoke to InfoQ afterwards, starting off with why IBM is involved with Swift:
Bailey: IBM has become a huge contributor to open source projects, and languages are no exception. We contribute to a wide set of languages, mostly in terms of enablement on IBM platforms, but we also have three languages that we have much larger contributions. These are Java, where we have a long history, and more recently Node.JS and now Swift. I've been involved in all three, and continue to contribute to all of them, although Swift is my current main focus.
Swift is interesting because, as a replacement for Objective-C, it already has a large developer base through the iOS and Mac ecosystems. This has led to Swift being highlighted as one of the fastest growing languages. It's also interesting because it offers different, but complementary, characteristics to Java and Node.JS, particularly around fast startup and small memory footprints.
Bohrer: The value of participation in any open source project is based on the technical foundation, relevance of the problem space to IBM, as well as by the size and health of the project's community. Swift was a natural project for IBM to join based on our existing investment in the language, the size of the Swift developer base as well as our vision of how Swift on the server could greatly improve the development of Mobile and Cloud workloads.
InfoQ: One of the bigger announcements when Apple open-sourced Swift was that it ran on Linux as well as on OSX. How functional is the Linux port when compared to the Mac port today?
Bailey: It's early days, but it's moving forward rapidly. The Swift language itself is there, it's the API support you could say is behind. On the Mac/Darwin platforms there is bridging between Swift and Objective-C code, allowing you to use the existing Objective-C API frameworks such as Foundation, Security etc. On Linux, there's no Objective-C runtime or bridging capability, so we're in the process of porting those APIs to a pure Swift implementation to allow them to run on Linux – and any other platform that Swift supports in the future.
The focus is currently on the Foundation APIs. You can track the progress, and obviously contribute code if you'd like to, via the GitHub project.
InfoQ: What's the performance of Swift like, and how does it vary between the Linux and Mac platforms? How does it compare to other server-side ecosystems like Java, Go and Node.JS?
Bailey: Modern native languages like Swift are generally characterized as having high throughput performance, a small memory footprint, and fast startup. The throughput comes from the strongly typed, non-dynamic nature of the language (we know what all the variables and types are and don't need to validate them at runtime), and the fast startup and small memory footprint occurs because there's no virtual machine to start, no need to compile code at runtime, and no need to allocate a large "mark-sweep" garbage collected heap.
We don't expect there to be any performance differences between the Linux and Mac platforms as such, as we're compiling down to the same instruction set in both cases. On Linux we have the scope for much, much greater levels of concurrency though as there's much larger boxes with more CPUs available. This is one of the reasons we've been applying a lot of focus to porting Grand Central Dispatch (aka libdispatch) and improving its implementation on Linux, as it underpins the concurrency classes in the Foundation APIs.
How the languages compare, and which is the best to use for any given workload or use case, is a much bigger topic though. There is certainly no "one size fits all" language, and in microservices architectures where there are advantages to using them in combination.
InfoQ: What are the benefits of having the same language on the server and on the mobile side?
Bohrer: We continue to see the creation of new applications and experiences that change the way we work and live. These applications are naturally driving the creation of cloud and server-side capabilities like data/device synchronization, data caching, background monitoring, and social graph notification routing. Additionally, we are seeing a number of these experiences being developed first on mobile, and often on iOS first. We feel it is a natural fit to support the creation of these new application stacks in Swift across both the client and cloud tiers.
Bailey: The immediate gain is in skills and code re-use. If you're already writing Swift code on the client side, you can re-use those skills to implement the server components of the application – including re-using some of the same modules used on the client.
Having the same language on both sides then also opens up a number of opportunities for client/server integration. It becomes possible to implement data sharing frameworks where you are abstracted away from the implementation of data serialization and transport under the covers.
InfoQ: Do you think we'll see Swift on other platforms, like Windows?
Bohrer: Going forward, I think we will continue to see the expansion of the number of systems that Swift developers will be able to target. As an open source project we have already seen work done to start targeting Raspberry PIs, Android, IBM's Power systems and even IBM's z System mainframes. I imagine it is only a matter of time until we see a Windows port as well.
InfoQ: How did the idea for the Bluemix Swift Sandbox come about? How is it implemented?
Bohrer: When Swift was open sourced, we knew this would require developers to - at a minimum - create a virtual machine, install Ubuntu, install Ubuntu packages needed by the Swift runtime, and finally, pull down the latest Swift binaries and install them on the system. All of this, just in order to be able and write and run some Swift code on Linux. We knew we could make this easier.
The IBM Swift Sandbox gives the worldwide development community one-click access to running Swift on the server. To better fully understand the capabilities available on Linux, we wanted to give developers full access to a Linux box when running their code.
When the Sandbox user clicks the "Run" button, the application passes the code to the server. This code then gets passed to run within its own Docker instance (already configured with the right version of Ubuntu, any needed system dependencies along with the latest Swift runtime from Swift.org).
Finally, the results of this compilation and run get passed back to the browser and are shown to the developer (along with code highlighting of any warnings or errors).
InfoQ: How do you run Docker containers security with the content, given that it is being submitted by end users?
Bohrer: As this code gets submitted anonymously, we knew we needed to run this code in a secure container. We had to put some constraints on how these container instances get run, including limiting their execution time to 5 seconds, the amount of memory they can allocate, the size of files they can create as well as blocking all outbound network communication.
For those developers wanting to dig deeper, and perhaps run their code unconstrained, we also shared instructions on our blog on how to create their own Swift docker setup on their machine.
InfoQ: How does the Bluemix Swift server compare with the Open Whisk framework? What benefits are there for writing Lambda code in Swift?
Bohrer: In addition to the IBM Swift Sandbox, we know that there are a number of ways developers might want to submit their Swift code in the cloud, so we include instructions for 3 ways. These include running Swift within a Docker instance; running Swift in a Cloud Foundry application, and finally, running Swift in a new event-driven cloud offering called Bluemix OpenWhisk.
The Swift runtime on IBM Bluemix leverages a Cloud Foundry buildpack to support having developers submit their Swift-based server applications to the IBM PaaS Cloud.
IBM Bluemix OpenWhisk is a new event-driven architecture runtime supported in the IBM cloud to create microservice-based applications easily based on a set of discrete cloud functions. We are really excited about the Swift support, in that this allows mobile developers to very easily deploy the right code to the right place for their application.
We have seen application architectures trend towards a microservices-based design and Bluemix OpenWhisk follows this trend to its natural conclusion. The ability to connect and compose these cloud functions is an incredibly powerful way to build highly scalable applications.
Classically, client-side developers have faced a set of inhibitors that kept them from participating in cloud development. These inhibitors include: lack of language portability (needing to switch programming languages based on the client or server), lack of server-side skills/interest (provisioning, deployment, scaling and monitoring), as well as prior knowledge of previously deployed cloud logic.
The Bluemix OpenWhisk offering alleviates all of these concerns. First, it has support for Java, JavaScript and Swift so client to server language portability is handled. Next, a developer only need to deploy functions to the service and OpenWhisk will handle provisioning and scaling that function, based on dynamic application needs. And finally, OpenWhisk supports the concept of sequences, which allow developers to build upon existing cloud actions by connecting their actions to other actions and/or action sequences. This avoids the need to read and understand the mechanics of the other actions in the system.
InfoQ: Finally, what is the Swift Package manager support that IBM has been working on, and how many packages does it currently have in its catalog?
Bohrer: The Swift Package Manager that was released in December provides an integrated means to build Swift projects as well as pull down and build any other dependent packages. The design of the package manager itself is very decentralized. We noticed that a number of people in the Swift community were immediately creating or porting Swift projects that leveraged the Swift Package Manager and posting them to GitHub.
To help the Swift community discover and share these packages, we created the IBM Swift Package Catalog. The catalog allows anyone to submit GitHub URLs of new Swift packages, and the catalog will add these projects to its list. Additionally, the catalog will discover any other new dependent packages added to its known packages along the way. We initially seeded the catalog with links to around 150 Swift packages, and the list has grown to well over 300 as of late March 2016.
Developers can browse the package catalog and can submit new packages by following the Submit a Package link at the top right. Swift for Linux can be downloaded from the Swift site or the ibmcom/swift-ubuntu Docker image can be used to experiment with Swift on Linux, as well as the web-based Swift Bluemix console.
About the Interviewees
Patrick Bohrer is a Distinguished Engineer in IBM’s Cloud division. His responsibilities include serving as the technical lead for the Mobile Innovation Lab in Austin, Texas, as well as, leading IBM’s Global Swift Engineering efforts. Patrick co-lead the 2012 Global Technology Outlook entitled MobileFirst which helped set the technical direction for IBM's current mobile and cloud efforts. Patrick received a B.A in computer science from the University of Texas.
Chris Bailey is responsible for the monitoring, support and serviceability of IBM runtimes, driving changes into the the implementations of these runtimes to enable application visibility and first failure analysis capabilities.
