Recorded – watch the full episode on YouTube.
When you like to see concurrency manifesto be implemented? And this is a when question. Do you think it's a Swift 6, Swift 8, Swift 18?
Chris Lattner: Swift 3 would have been better. Is that an option in the parallel universe when anything is possible? So I don't know when it will happen. I suspect that this will be a pretty high priority. A lot of it comes down to getting the model right and I feel like, over the course of the last few years, we as a community have been slow baking some of these ideas. I think that there's quite good consensus that Async/Await is the right way to go now.
"I think, that over the course of several years, the community's kind of come around to that and I think that people generally think that would be the right way to go."
When that manifesto was first written, that was not clear to people. In fact, the entire reason I wrote that manifesto is because I was accused by certain people of taking the language on a random walk. And they're like, “no, no, no. You just think that async/await is a cool thing to do.” And I'm like, “no, actually this is continuous with a very nice future that could do lots of different things.” I think, that over the course of several years, the community has kind of come around to that and I think that people generally think that would be the right way to go.
Now there's still implementation decisions and I think that a lot of the discussion I've seen gets confused between what is async/await versus what is the threading model, the runtime, how do stacks get managed, how do processes get spun up, do you have lightweight threads or heavyweight threads. Like all that kind of stuff, which is actually quite orthogonal to Async/Await.
And so what I advocate for in this space is simple features that are orthogonal to each other that compose well, and so async/await is what's called an effect on a function so that you can tag it kind of like throws combined with a simple state machine transformation. And that's it in my opinion, plus some standard library helper functions and things like that. Just doing that is a pretty bounded amount of work and would allow a lot of really nice APIs and then you push through and you say, well, what is the threading model? What is these other pieces? And you do that in a staged manner so you get experience with it.
So I don't know. I don't have a crystal ball. I can't speculate when a specific thing will happen, but I feel like it's getting closer so I feel like it could come in the next year or two. Again, Swift 3 would have been better!
"It's a leading edge of a sword towards a bigger concurrency model as well, so it's one of these necessary but insufficient features."
Chris Lattner: Absolutely. I agree. I mean it's a leading edge of a sword towards a bigger concurrency model as well, so it's one of these necessary but insufficient features.
Paul Hudson: It's interesting that if it is vaguely in the near future, two or three years, whatever it happens to be, which is great, we only recently just saw
Result being added to Swift. And this is one of those things where we had, it was almost either the first year, 2014 or early 2015, the first community result project span up and they've been going for years and they're brilliant for handling a
Result type in Swift.
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SPONSORED In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.
Link copied to your pasteboard.