My take: Swift Concurrency has gone from being somewhat understandable to being really, really hard to apply and understand properly.
I get that we can stick with Swift 5 language mode, but none of us wants to do that.
I hope that WWDC brings some understandable instruction alongside improved tooling, because right now we're all reliant on @mattiem sharing what he has worked out (thanks Matt!).
@tonyarnold@krzyzanowskim@everything@mattiem Honestly, after the “Combine Feint,” as a hobbyist/semi-pro, I’ve just backed away from implementing Concurrency altogether, and just focused on SwiftUI, where at least the progress has been close to linear. (1/2)
For my crowd, I would love a Big Nerd Ranch book on ecosystem-wide SwiftUI app development that doesn’t really go further than async/await, and then a separate book on Advanced Swift that goes deep on the big stuff behind Swift 6. Trying to piece things together from occasional articles and forum posts is just leaving people behind. (2/2)
@jpurnell I’m a teensy bit worried about this comment, because you cannot use async/await safely without understanding how all of concurrency works. And I think that’s something that is causing a lot of the heartburn we’re seeing now.
@mattiem That’s almost exactly my point. Async/Await was pushed out right after Combine and the messaging seemed like all we had to do was throw a little sugar on our existing functions and get Concurrency magic.
But by the time I got the message and got the mental energy to walk away from Combine…what seemed like a slightly more cross-platform approach to the same thing turned into “Here Be Dragons,” and now there isn’t a line between BNR Intermediate book and Eidhof Deep Dive
@jpurnell Yeah this is a very legitimate criticism. Apple made an invalid state possible, the default, and sold it as a reasonable thing to do. Lots of people are going to be pissed about this. But it is also true that Swift 6 will make some (but absolutely not all) of the pain go away, especially for straightforward usage.
@mattiem Honestly, I’m excited to take the leap, but after the last four years of half-steps and side-quests, I just want one narrated experience with an end-to-end curriculum on “the new approach,” instead of hoping I’ve followed the right people and pieced together the right articles (yours are really helpful though!)
@krzyzanowskim@jpurnell It also doesn’t help that basically all first page search results for any swift concurrency topic contains blog posts with errors…
@jpurnell@mattiem At this point my plan is to basically not touch any of it until I can find a full month of time to close everything else and go through all those bookmarked articles and Mastodon threads from last 2 years one by one...
@jpurnell@mackuba I would totally ignore anything that was written before Xcode 15.3 came out. It's all wrong. And, like 50% of the concurrency problems people run into won't be relevant once Swift 6 actually ships. So, waiting is a very reasonable thing to do.
Swift concurrency is super easy to use wrong. So everyone did. And now people, after writing real (but wrong) code are starting to learn how it actually works and trying to fix their code and mental models simultaneously. And that is a deeply frustrating and difficult task.
@mattiem I will absolutely allow it! I'm in your debt for sharing your own journey here — it has helped me immensely.
I agree with your take.
I also strongly believe that the tooling, both through error messages, fixits and syntax highlighting/visuals should be providing a far richer experience to guide people through this period.
Remember the static analyser visualisations in earlier versions of Xcode? That, but for this.
@tonyarnold Well I’m really glad to hear that! I shall continue 😀
As for source-level visualizations, I don’t know for sure anything actually makes sense. But isolation is so foreign now that it may feel that way. I’m planning a blog post about this.
That all being said, I'm really glad that people are sharing their woes, and their discoveries, and that members of the Swift team such as @holly are doing their best to help everyone understand.
@tonyarnold Confusing error messages are compiler bugs - please report them! There’s room for improvement in probably every compiler error. Reporting them as bugs is important because there are thousands of these messages in the compiler, so I need signal on what’s confusing folks to understand how to best prioritize.
Anyway, initializing isolated state is on my list since a bunch of folks have posted forum threads about it. Also, compiler notes to show where global actors are inferred from.
@holly I’m not using Swift at the moment, but very interested in what it’s doing! I’d love a clear and concise definition of isolated and non-isolated. I haven’t found one on any of the official docs I’ve seen. This might just be googleability. However, I imagine errors using those terms will only be as clear as the terms themselves.
I’m guessing from context; the English definition; and a proposal that mentioned “data isolation”, that isolated means it doesn’t pass between concurrency contexts, non-isolated means it does/can. I’m guessing implementing Sendable is one way to make something safely non-isolated.
Although all the official blogs and proposals I’ve seen seem to assume you already know what they mean and what their relationship to each other is (in the context of Swift concurrency). Non-official blogs I’ve seen seem to try and exhaustively define whether something is isolated, as that’s a thing that crops up in errors, but it seems to me like a good definition would save the need for that exhaustivity.
Add comment