Swift Evolution: Actors
The idea of the &quot;mailbox&quot; reminds me of Dispatcher.BeginInvoke in C# on Windows. It is very powerful, but can also lead to messy code where many threads are mutating shared state and failing to fully reason about all the other mutations that can happen.<p>Systems with explicit communication, i.e. based on queues, encourage the programmer to limit the number of possible ways in which worker threads can interact with the thread that manages mutable state. They also require something like a big switch statement where all possible interactions are listed in one place. It seems like in actor-based code, all the possible interactions with the mutable state could be spread across the code base.<p>On the other hand, these hand-written message loops and switch statements are essentially the same code that the compiler would generate for an actor&#x27;s mailbox processing loop. One could argue that writing them by hand is a waste of effort. Programmers simply need to use discipline. (Similar to virtual dispatch in C++, for example.)<p>I am curious about the opinions of programmers more familiar with concurrent architectures. Does the actor model make it easy to write concurrent spaghetti code?