I think there is a semantic difference. Each actor has one mail box. So when sending a message to it, the message is sent to the pid (address) of the actor. So the actor become the central abstraction without the need for channels.

To emulate that with channels it is like saying you have one default channel created for each task. Instead of sending a message to the task, it is sent to a channel and instead of just a simple receive, the task has to has a reference to the same channel.

Another way of thinking about it, it is like having a graph of components and one model emphasizes the nodes (actors) and the other emphasizes the edge (channels) as the central abstraction.

Making a strong association between tasks and message boxes like erlang does makes too many assumptions. That'd be an apt choice for many languages. But for Rust, as a systems languages, that seems like a poor choice.

> But for Rust, as a systems languages, that seems like a poor choice.

Yeah I can see that I guess. It is a lower level language so it would be the same as asking for closures or garbage collection in assembler?

> Making a strong association between tasks and message boxes like erlang does makes too many assumptions.

It does, and often having good assumptions is nice. One can argue that at some point unless the system is not C then someone can say it is making "assumptions".

In their documentation they do mention how they are trying to emulate Erlang (they even have supervision trees for tasks) so my point was that they left a critical semantic feature out.

Even if a system is C you can say it is making assumptions. The point is to make as few as practical.

I think they are trying to learn from Erlang, not replicate it completely. The key point is that the missing feature can be pretty trivially made up for by libraries and convention. Which again, seems like an apt choice for a systems language.

I meant that I'm all for Rust providing the mailboxes abstraction too but not for channels to go away.