You probably have seen this, but I think some of the points are worth highlighting here. The biggest surprise to me was that the refined memory model was scheduled for Swift 4 phase 1, which, after all, does make perfect sense when aligned with ABI stabilisation:
Adding an (opt-in) Cyclone/Rust inspired memory ownership model to Swift is highly desired by systems programmers and folks who want predictable and deterministic performance (for example, in real time audio processing code). More pertinent to the goals of Swift 4, this feature is important because it fundamentally shapes the ABI. It informs code generation for “inout”, how low-level “addressors” work in the ABI, impacts the Swift runtime, and will have a significant impact on the type system and name mangling.
And, as I mentioned concurrency model in the previous issue:
First class concurrency: Actors, async/await, atomicity, memory model, and related topics. This area is highly desired by everyone, as it will open the door for all sorts of new things on the client, server and more. We plan to start formal discussions about this in Phase 2, but it is unfortunately crystal clear that a new concurrency model won’t be done in time for the Swift 4 release. This is simply because it will take more than a 12 months to design and build, and we want to make sure to take time to do it right. It also makes sense for the memory ownership model to be better understood before taking this on.
Overall, this is big and great news, which will definitely impact both performance and feel of Swift for server-side code. As Swift evolution is proceeding in an open way, I will track these proposals closely myself and encourage you to provide your feedback on swift-evolution mailing list.
Surprisingly enough, this proposal is still marked as “Active Review”. I haven’t seen much feedback for it in the mailing list, but it does seem to be quite important in the light of source-breaking changes in Swift 3.0 and possibly 3.x and 4.0. Check it out and write a short reply on the mailing list to improve its chances of being accepted for Swift 3.0!
A fascinating Swift London talk about performance of Swift on Linux by Chris Bailey and Nic Jackson. Interesting tidbit: Chris stated that in their benchmarks Kitura was faster than Express.js and Vapor, still slower than Zewo. The part of the talk by Nic covers all of the interesting implementation details of protocols in Swift. Ever heard of protocol witness tables? Wondered what implications protocols have on performance of your Swift code? All explained in this great talk.
Update: Qutheory has just published an article in which they weren’t able to reproduce the same results of Vapor vs. Kitura benchmark. I look forward to seeing the actual testing methodology used by IBM to get the results of their tests.
A simple and concise introduction of machine learning algorithms. In this first part some basic terminology and decision trees are covered with clear visualisation of all data flows.
Docker 1.12 was released last week with built-in container orchestration. While this may not be as advanced as Mesos or Kubernetes, this is great to get started with container orchestration, especially with a nicely implemented Docker app for Mac being available.
This patch adds the CloneDetector class which allows searching source code for clones. For every statement or group of statements within a compound statement, CloneDetector computes a hash value, and finds clones by detecting identical hash values. This initial patch only provides a simple hashing mechanism that hashes the kind of each sub-statement. This patch also adds CloneChecker - a simple static analyzer checker that uses CloneDetector to report copy-pasted code.
In other Nuclide-related news:
Autocompletion for #swiftlang is in Nuclide trunk. Build from source to use it now; official release soon.
A post by Jesse Squires about use of enums in Swift for configuration of exposed APIs. While this pattern seems obvious, it’s not without its drawbacks, not being extensible and flexible in most of the cases. The post also provides a good alternative with nice descriptive examples.
Protocol Buffers library that supports both Swift 3.0 and 2.2.
SwiftGPIO was recently updated for Swift 3.0.
This library provides an easy way to interact with digital GPIOs and use SPI interfaces with Swift on Linux. You’ll be able to configure a port attributes (direction,edge,active low) and read/write the current GPIO value. And you will also be able to use the SPI interfaces provided by your board or a software big-banging SPI. It’s built to run exclusively on Linux ARM Boards (RaspberryPis, BeagleBone Black, UDOO, Tegra, CHIP, etc…) with accessible GPIOs.