> However, in most cases threads are no more complex than callbacks, actors [...]
You are mixing the two concepts. The distinction is between threads/actors vs callbacks. Not threads and callbacks vs actors.
If you disregard isolated heaps and memory an actor is just a thread plus a queue. Other threads write to the queue and the threads gets messages from queue and executes them.
The real distinction is callbacks vs threads and actors thought. And I agree with original point. Callback-based concurrency is more complicated and more challenging to write than threaded-based concurrency.
> Also, in lots of languages multi-core != concurrent. You can have 10,000 actors using a single core. In fact writing a scheduler that can efficiently distribute actors between different cores is probably where the complexity Doron Rajwan refers to lies.
What do you mean by multi-core? Languages don't come with cores, hardware does. Do you mean that CPU-bound units of concurrency (threads, actors, processes, co-routines) can be dispatched onto multiple CPUs if those exist? Yeah some languages (or more precisely their runtimes and libraries) can't do that. Like Python has the GIL so CPU bound threads can't work. But threads work great for IO bound threads.
> If you disregard isolated heaps and memory an actor is just a thread plus a queue. Other threads write to the queue and the threads gets messages from queue and executes them.
Exactly. Turns out, this is what good thread design looks like anyways, no matter if they are OS or green threads. However, if you put on your safety goggles and lead apron, you can also do other "unsafe" things which may lead to performance boosts. For example, why toss the giant JSON blob into the queue intended for the JSON decoder, when you can just put a pointer to the blob? Of course, then the burden of cleaning up the blob is up to you, the developer, not the runtime.
> What do you mean by multi-core?
I mean distributing N actors/green threads/etc. to run in parallel over M cores. This is not a trivial "write it in a weekend" type of task and support for it may or may not be built into language+runtime. For example, Erlang had concurrency but not parallelism for a time.
You are mixing the two concepts. The distinction is between threads/actors vs callbacks. Not threads and callbacks vs actors.
If you disregard isolated heaps and memory an actor is just a thread plus a queue. Other threads write to the queue and the threads gets messages from queue and executes them.
The real distinction is callbacks vs threads and actors thought. And I agree with original point. Callback-based concurrency is more complicated and more challenging to write than threaded-based concurrency.
> Also, in lots of languages multi-core != concurrent. You can have 10,000 actors using a single core. In fact writing a scheduler that can efficiently distribute actors between different cores is probably where the complexity Doron Rajwan refers to lies.
What do you mean by multi-core? Languages don't come with cores, hardware does. Do you mean that CPU-bound units of concurrency (threads, actors, processes, co-routines) can be dispatched onto multiple CPUs if those exist? Yeah some languages (or more precisely their runtimes and libraries) can't do that. Like Python has the GIL so CPU bound threads can't work. But threads work great for IO bound threads.