I think the main issue with GCD is the potential for deadlocks in serial queues (which it doesn’t really help you with), and the related problem of thread explosion in concurrent queues.
Actors make protecting shared mutable state really easy, solving a big chunk of the reason you’d want to use semaphores and serial queues in the first place. If you stick with async/await/Task{}/actors, you’re guaranteed to only have the optimum number of threads that can saturate cores, and won’t have deadlocks. If you use Sendable properly and heed all the warnings, you’re a good way towards the kind of “fearless concurrency” that Rust gives you. It really is pretty great IMO compared to GCD.
I’m actually happy with this decision… it was very much done intentionally to prevent the kind of thread explosion that is all too common in GCD. The criticism of GCD I linked to was very skeptical of actors for this reason; if the implementation decides to add more threads to avoid deadlocks, you get the same performance pitfalls as in GCD, and thankfully that didn’t happen.
In practice, I’ve found that avoiding deadlocks is as simple as grepping for `DispatchSemaphore|DispatchGroup` in your codebase and eliminating them with extreme prejudice. If you stick to Tasks/TaskGroups/Task.sleep, there’s no real possibility of accidentally introducing deadlocks unless you try really hard to do so.
And yeah, logical races can still happen in actors, but it’s easy enough at a glance to tell whether you’ll run into one… if you avoid using `await` in a section of code that needs to run exclusively, you’ll be fine. (Even with `await` calls you may get lucky if there’s no actual suspend point happening, but a quick and dirty rule is just “don’t call await and your code will never be run concurrently.”)
You’d think so but then you realize that framework code you call into might decide to do this and you wouldn’t know until it deadlocked. On a 6-core iPhone 13 this is probably not going to be noticeable, but that’s probably not true on a 2-core iPhone 6s…
But if you’re calling into framework code which is using GCD, the queues it dispatches into will be run on a separate GCD thread pool. If said framework code is using a semaphore or lock to block your calling (Concurrency) thread, then it stands to reason there’s another thread in the GCD pool which will eventually unlock it. (Or else it’s a deadlock no matter what you do.)
I haven’t come across any framework code which violates this, although maybe you’ve run into problems I haven’t.
That said, I'm really not sold on actors. I think CS as a whole hasn't really landed on the right abstraction for concurrency yet, actors seem a bit experimental, and GCD is plenty good enough in most cases.
Yep. If anyone had doubts that the language was no longer the one Lattner designed, SwiftUI should've put the nail in that coffin.
Swift is an imperative, statement-oriented, language. In fact, I get kind of frustrated when writing Swift after spending some time with Rust: I just love writing `let x = if foo { 1 } else { 2 }` or `let x = match foo { ... }`, and it's ugly as hell to try to assign a variable from a switch statement in Swift, etc. BUT, that's okay- I'm almost sure that zero programming languages were written with my opinion in mind, and Swift is Swift.
But, SwiftUI is declarative, which just doesn't work with literally the entire rest of the language. So they added result builders and these weird, magical, annotations just so we can have a UI DSL.
Error handling is now inconsistent and annoying, too. The original approach was to use this quasi-checked-exception syntax where you mark a function as `throws`, and all callers are forced to handle the possibility of failure. The difference between this and Java's checked exceptions is that the specific error type is not part of the signature and therefore the caller only knows that they might get an Error, but not what specific type of Error.
They even have a mechanism for higher-order functions to indicate that they don't throw any of their own errors, but will re-throw errors thrown by function arguments. Clever.
Okay, fine. Pros and cons to that approach, some like it, some don't, etc, whatever. Except then they realized that this approach falls flat in some scenarios (async/promises), so we really just need to go back to returning error values. So they stabilized a Result type.
So, now we need to figure out when we're writing a function if we want to return a Result or make it throw. And, even more annoyingly, Result has a specifically-typed error variant! It's actually a Result<T, E>. Which is it, Swift team? Should immediate callers care about specific error types or not?
Just recently, they landed the async and Actors stuff. Async is fine and great, and is consistent with the imperative syntax and semantics of the language, and it even supports `throws`, IIRC. But Actors? What the hell is that? That's totally out of left field for the rest of the language.
I used to really enjoy Swift in the 2.x to 3.y days, but it really seems like it doesn't even know what it wants to be as a language anymore, which is a real shame- it had a real shot to take the wind out of Rust's sails, IMO (The number one "scary" part of Rust is lifetimes and borrow checker. Swift has CoW structs and auto-ref-counted classes, instead, which can be seen as more appropriate for higher level tasks than writing system libs, etc).