> Your actor may block on its message queue (and an infinite computation would mean you'd never consult the queue again), but during a message wait it doesn't n

> Your actor may block on its message queue (and an infinite computation would mean you'd never consult the queue again), but during a message wait it doesn't necessarily block a thread. That's sort of the point of a good Actor model implementation. A thread can block on a syscall or a "while(true);", but won't necessarily idle one of your CPU cores. That's likewise the point of a good task scheduler. Actors are threads, just they tend to be implemented in userland rather than as OS threads. > Perhaps you don't know this, but every lock&block system has an equivalently performant Actor-based system, and vice-versa. Knowing that they're equivalent (up to "frictionless surface" assumptions for performance, ignoring what primitives the hardware provides) is a significant part of why I don't take claims of the actor model's magicalness seriously. > P.S., Just because you haven't heard of these languages doesn't mean they are not widely used. What does your personal experience have to do with the viability of a technique? I have heard of them, always in terms of "this is awesome, what's wrong with people that almost nobody actually uses it?".