Swift Standard Library Signaling

The Swift standard library is small at best. Apple's documentation provides a starting point for understanding it. However, it does not cover the standard library in its entirety. For the curious, a more comprehensive look can be had over at SwiftDoc.org.

Popular programming languages of the past 20 years have tended to incorporate a large standard library. Consider, for example, Java and Python. Both have a batteries-included philosophy. On the other hand, older languages that made it big, like C and Fortran, tend to have small standard libraries. This distinction may be attributed more to the time when they were developed (in terms of hardware capability, especially memory & disk capacity) than anything else. It should also be stated that Java (with the JVM) is more than a programming language; it is a platform unto itself.

So, why in 2014 did Apple decide on such a limited standard library for Swift? Is it a function of the youth of the language? The standard library has evolved and slightly expanded over the past (nearly) year since Swift was released. It may very well expand in the future. There is a more obvious rationale for explaining Swift's anemic standard library than its youth though.

Let's consider other modern languages with tiny standard libraries. JavaScript was purpose designed to run within the confines of a web browser.  Since it piggybacks off of an existing platform with an extensive API (albeit retroactively designed for it), its standard library can remain relatively slim. In a similar vein, languages that run on the JVM, like Clojure and Ceylon, can take advantage of Java's extensive libraries and don't need large standard libraries of their own.

Swift was designed to work with Cocoa and Cocoa-Touch, also therefore piggybacking off of an existing comprehensive platform. By not including a large standard library, Apple is indicating to developers that Swift is expressly designed for its platforms. "Well duh," you might say. But sometimes corporations develop new languages that they hope to eventually have adopted by the wider world beyond the gates of their platform. Wasn't that Sun's hope for Java? Isn't that Google's hope for Go and Dart? They figure being in control of a language widely adopted across the entire computing world is only to their benefit and will lead to additional developers on their platforms.

Perhaps Apple is so large and influential that it has no such concerns. Or, perhaps Apple's need to work within the confines of its existing software technology trumped these pursuits. Or, most likely, perhaps Apple simply prefers to keep its language technology proprietary as a competitive advantage.

In some sense, Swift is to Cocoa as Clojure is to the JVM and JavaScript is to the web browser (as we know, it eventually broke free). Yes, it may be open sourced in the future, and there may be alternative implementations (see Silver for example); but Swift's small standard library is Apple signaling that it was not made for the world, but instead the enclaves of iOS and OS X. As developers, we have to fill in the gaps. If you head over to GitHub, you'll find projects that do just that – provide fundamental functionality in pure Swift (without utilizing Cocoa) that is usually provided by a standard library. I have two such projects in the data structure space: SwiftGraph and SwiftPriorityQueue.