Contents
Intro
In this note I will try to track what’s happening with Swift and concurrency. I already have mentioned Swift some (https://www.teigfam.net/oyvind/home/?s=Swift) and I won’t repeat here – only to say that there per se, at the moment, is no concurrency support in the language. Swift 3 users are supposed to use GCD (Grand Central Dispatch) – which also addresses parallel processing (multi-core).
As I read the script on the wall then I would be surprised if concurrency shows up in the language with Swift 6.0. (Statement 8Aug2017)
Swift was designed and built by Apple under the leadership of Chris Lattner, the (co)creator of LLVM compiler infrastructure and Clang (that Stallman doesn’t seem to like: Re: clang vs free software) – and now also Swift.
In August 2016 Chris Lattner, in a note to swift-evolution, asked people to wait with concurrency until the discussions for future Swift 4 (What’re the Swift team’s thoughts on Go’s concurrency?). As a «language owner» he seems to be entitled to do that:
There are many folks interested in concurrency topics related to this, but we need to stay focused on finishing Swift 3 and then moving on to Swift 4 stage 1 goals. As that work is cresting, we’ll start discussions of concurrency, and may even be so bold as to start a new mailing list dedicated to the topic, since it is such a wide reaching topic.
Until we get to that point, please resist the urge to jump ahead 🙂
Update 27April2017, see the discouraging(?) Swift 4.0 proposal (below).
Aside: Chris Lattner left Apple for Tesla to become Vice President of Autopilot Software in January 2017 ([swift-evolution] Update on the Swift Project Lead, Macrumours: Swift and Xcode Head Chris Lattner Leaving Apple for Tesla This Month and phoronix: LLVM Founder, Swift Creator Chris Lattner Is Leaving Apple: Joins Tesla). (Aside 2: I hope he didn’t back out because he thought concurrency was too difficult?) Ted Kremenek, who up to now has been leading the Languages and Runtimes team at Apple will lead the Swift project from now on. Isn’t concurrency much about good abstractions for runtime scheduling? After a day or so a comment was added by Lattner on swift-evolution, see Daring Fireball: CHRIS LATTNER ON TED KREMENEK.
It’s going to be exciting to see how concurrency or multi-core added to a language in a revision four of it might look. It’s easy to think that it would be as an afterthought. Whether that is bad or good, then, remains to be seen. .
Concurrency issues with 3.0
Searching for concurrency in swift-evolution (or «thread-safe») I get some hits. The language designers are certainly preoccupied with the issues. After all, there is concurrency through GCD. Here are some matters I found, showing that the issues are not under the carpet:
- «Makes it feasible to fix existing concurrency issues in Set and Dictionary indices» (in A New Model for Collections and Indices of April 2016). In the same: «The issue that we were previously unaware of is that this scheme is not thread-safe. When uniquely-referenced storage is being mutated in place, indices can be concurrently being incremented (on a different thread). This would be a read/write data race.»
- «The NSLock family of classes and protocols will likely be revisited as part of the general concurrency effort in the next release of Swift. Therefore we will keep the NS prefix» (in Drop NS Prefix in Swift Foundation of May 2016)
Swift 4.0 proposal
I can see no mention of concurrency in the Swift 4.0 proposal (as of 27April2017) at https://github.com/apple/swift-evolution
Swift 5.0 and beyond
It seems like concurrency is getting some attention, but I am surprised to see how little. But they do seem to be concerned with making it usable from the start. But the path seems to be set: making it correct for «callback-heavy» code.
Rich Hickey might have a job to do here. I learned a lot from his Clojure core.async, lecture (45 mins). He discusses the motivation, design and use of the Clojure core.async library. See http://www.infoq.com/presentations/clojure-core-async. Additionally you can download the soundtrack from this as an mp3. This is also discussed in note 084 (search for Rich Hickey there).
Letter 8Aug2017: Swift 5: start your engines
In a letter headed «Swift 5: start your engines (Ted Kremenek)» (to swift-evolution-announce-request@swift.org, dated 8Aug2017) he writes that:
Other focus areas (including laying the groundwork for concurrency)
One of those that I wanted to highlight is laying the groundwork for concurrency. It is a non-goal of Swift 5 to roll out a full new concurrency model. That is simply too large an effort to do alongside ABI stability. However, it is important that we start making progress on discussing the directions for concurrency and laying some of the groundwork. This may take the form of specific enhancements to the language that get implemented, depending on where the discussions for concurrency lead and how they align with the priorities for delivering ABI stability in Swift 5.
GitHub 8Aug2017: Development major version: Swift 5.0
On GitHub (here) this reads as:
Development major version: Swift 5.0
Expected release date: Late 2018
Laying groundwork for a new concurrency model
We will lay groundwork for a new concurrency model, especially as needed for ABI stability. Finalizing such a model, however, is a non-goal for Swift 5. A key focus area will be on designing language affordances for creating and using asynchronous APIs and dealing with the problems created by callback-heavy code
I discoved in Apr2019 that Graydon Hoare wrote «What next» in Aug2017. Here’s an exerpt from it:
Coroutines, async/await, «user-visible» asynchronicity
It’s in vogue at the moment for new languages to have something like async/await. This does not mean it’s a done deal: lots has been done, but lots is still messy. The boundary between synchronous-world and asynchronous world — in terms of types, control flow, correctness, errors, modularity, composition — is still very awkward. Whether and how to mitigate between different synchronicity regimes, especially across FFIs or differing runtimes, is hard. Integration with effects is hard. Integration with parallelism is hard. Which parts need to be supported by the language and which parts surface to the user is hard. Cognitive load is still very high.
Since this was from a man inside Swift I think it rather interesting. I’d love to know what his thoughts about this are now. (There are some newer thoughts at Rust 2019 and beyond: limits to (some) growth.)
However, this became my first post in DreamWIDTH: What got me here was a sincere answer