I like ZeroMQ but this slideshare doesn't deliver any substance at all. For an overview, skip it and check out the white paper (if you can call it that) cowritten by the same guy (Pieter Hintjens) instead:
You know how I wrote my first concurrent programs? Create threads with pthread_create(3), and pass ownership of objects by sending pointers over connections created with pipe(3). Which sounds an awful lot like this cure-all actor model (which I hadn't heard of yet) that requires languages almost nobody's ever heard of.
Of all the approaches taken to multithreading, only one is known to work properly. That means, it scales to any number of cores, ...
clone(2) and socket(7)
... avoids all locks,...
Your threads/actors still block waiting for messages. I've seen an example of someone using this to write a mutex in Erlang.
... costs little more than conventional single-threaded programming,...
Probably depends how much you have to twist your code to fit this functional+actor model.
... is easy to learn,...
If you discount having to learn a whole new language and turn your code inside-out.
... and does not crash in strange ways.
Instead of crashing, it hangs because you accidentally wrote a mutex.
This statement suggests to me that you've got some fundamental misunderstandings about the nature of actor based programming. 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.
If you write a series of symmetric calls that create a dependency, then yes, you will deadlock; the Actor model can't work its magic when you explicitly model blocking calls.
Perhaps you don't know this, but every lock&block system has an equivalently performant Actor-based system, and vice-versa. (See: http://www.sics.se/~adam/pt/duality78.pdf) What this means, for programmers, is that whichever model fits our current problem best is the one to use. We can make either one performant.
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?
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?".
What I see is that they program something buggy, but where the bugs are rare enough to make the program work most times.
The FOSDEM streaming server seems to be timing out right now.