Topics

Featured in Development

Peter Alvaro talks about the reasons one should engage in language design and why many of us would (or should) do something so perverse as to design a language that no one will ever use. He shares some of the extreme and sometimes obnoxious opinions that guided his design process.

Featured in AI, ML & Data Engineering

Today on The InfoQ Podcast, Wes talks with Katharine Jarmul about privacy and fairness in machine learning algorithms. Jarul discusses what’s meant by Ethical Machine Learning and some things to consider when working towards achieving fairness. Jarmul is the co-founder at KIProtect a machine learning security and privacy firm based in Germany and is one of the three keynote speakers at QCon.ai.

Featured in Culture & Methods

Organizations struggle to scale their agility. While every organization is different, common patterns explain the major challenges that most organizations face: organizational design, trying to copy others, “one-size-fits-all” scaling, scaling in siloes, and neglecting engineering practices. This article explains why, what to do about it, and how the three leading scaling frameworks compare.

There are also two separate packages available; the Swift package manager and the Swift build tools which can be used to build the Swift compiler and environment. There's more information about the package manager along with a community proposal for a new package manager (which shows how hard Apple is working at making this a successfully open source project). The PackageDescription module introduces a new type, Package, which represents metadata about a version and a name, as well as a list of dependencies. The implementation appears to be influenced with NPM, in that the dependencies are represented as source dependencies to remote Git repositories; when the build is executed, those dependencies are checked out, compiled to statically linked libraries and then included in the application. The package is kicked off by running a new swift build command, which downloads any dependencies defined in the Package.swift file. Dependencies are versioned using semantic versioning (which may be enforced in future), although it's not yet clear whether exact package versions can be specified or only a single version. The example given in the documentation shows:

Since Swift is built upon tools like LLVM and Clang, there are forks of swift-llvm, swift-clang, swift-lldb and swift-cmark which is used to generate documentation for the Swift source files. Unlike their SVN counterparts, these are hosted in Git and will be much easier to maintain in the future.

Because Swift libraries are copied into executables, the Apache License has a runtime library exception added which permits the application to be used without providing attribution:

As an exception, if you use this Software to compile your source code and portions of this Software are embedded into the binary product as a result, you may redistribute such product without providing attribution as would otherwise be required by Sections 4(a), 4(b) and 4(d) of the License.

This text is added at the end of the standard Swift license, which means that although it is based on the standard Apache License there may be some considerations necessary for legal re-approval. The idea of runtime exceptions is not new; for example, Oracle licenses Java under the GPL license but with a classpath exception that allows code to be linked without using the full GPL.

Finally, one of the main questions about Apple's open-sourcing of Swift is: would it run on other operating systems? The answer is yes; there is a Linux port and there are pre-built binaries for Ubuntu available from the Swift.org download page, although it isn't quite as full-featured as the OSX port.

Swift on Linux does not depend on the Objective-C runtime nor includes it. While Swift was designed to interoperate closely with Objective-C when it is present, it was also designed to work in environments where the Objective-C runtime does not exist.

Fortunately, you can run and debug Swift applications on Linux using the REPL so it's possible to get started with Linux and Swift easily and quickly. There is some missing behaviour; for example, those things that require the Objective-C bridge (such as some String APIs that use NSString's implementation under the covers, or classes marked with @objc) will not work on the Linux port at the moment. There are also some disconnects between general C APIs such as variable args support and limited libdispatch functionality, which is being worked on the GitHub project.

Will you be interested in learning Swift now that it's available outside of the Apple ecosystem?