No idea why you got downvoted. The fact that the first implementation of the actor system is most certainly going to be on top of libdispatch makes it a very interesting property. Libdispatch is really not known for being able to spawn thousands of "light thread". And so there is indeed a potential pitfall in making asynchronous + concurrent code easier.
However, after having read a lot of the swift proposal relative to concurrency, i am still unsure if the end result of production code is going to be lots of actors running in parallel, or just lots of async calls multiplexed on a few OS threads.
You can easily have thousands of tasks (blocks) in dispatch, and thousands of queues as long as they're targeted to the same base queue.
The issue with dispatch is that it wasn't communicated enough that you want to have a few base queues and then a tree of other serial queues on top of that, so people end up running too many CPU threads at once, on a device that often has less than one core free at a time.
However, after having read a lot of the swift proposal relative to concurrency, i am still unsure if the end result of production code is going to be lots of actors running in parallel, or just lots of async calls multiplexed on a few OS threads.