I'm interested to revisit all this in Swift 6, with its superior sendability support etc.
I love the actor model in principle, yet I almost never use it in real code, because it just inevitably seems to run into problems. From Apple & 3rd party frameworks which are allergic to actors (e.g. @MainActor protocols) to the myriad problems with sendability, etc, I just so often end up feeling forced into just using locks / semaphores, or dispatch queues.
I realise the above is very vague, but that's the high level summary from my perspective. Spherical actors in a vacuum work great, but unfortunately the real world is full of actor-hostile code that I can't fix. 
5 Likes
I don't think it helps that the first WWDC video0 to dive deep into actors and reentrancy apparently gave us the wrong solution1 (i.e., uses unstructured tasks). It's difficult to have discussions with other developers about reentrancy (and many other swift concurrency patterns) since the most authoritative documentation for anything more than the most basic use cases seems to be random forum posts by core contributors.
5 Likes
I just noticed that storing unstructured tasks is also a suggested solution in Apple's tutorials as well Caching network data | Apple Developer Documentation
2 Likes
Just to be clear, I made my statement about semaphore designs in response to a suggestion that it should end up in the standard library. People have problems today, and they shouldn't feel bad about using the tools they have on hand to solve them. If you're designing a library, though, I would encourage you to think about issues like priority inversion, cancellation, and so on. Even if you don't have the tools or time to solve those problems in your library today, try to structure your APIs in ways that could eventually be improved to avoid problems like that, rather than baking in a more general use pattern that lacks the necessary structure.
10 Likes