After a couple of years of writing erlang full-time, tying mailboxes to processes is one of the things that really bugs me. It conflates mutable state, addresses and queues into one construct. Using channels allows multiple writers/readers per queue, passing the channel as a first class value and allows transparent task restarting without needing global address registration per task.
I disagree. I think tying both together produces a new abstraction -- the actor. Not having it that way, offers little more than a thread and a bunch of queues.
Presumably you could still use a queue to provide the semantics you want, even now? Or have another actor that acts as the queue. But I think that use case doesn't warrant decomposing actors into channels and tasks.
I believe the idea here is that the language would provide an actor construct as a member of the standard library, built using the concurrency primitives demonstrated above.
