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.
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.