I'm not too well-informed about the state of the discussion about which model is better, so I would like to ask a pretty straight question: Does it look like two opposing views having really heatened dispute? E.g. like prototype/class based OOP or dynamic vs. static typing
(though these are really not much fitting examples, I just do not know how to express my question more clearly)
In some concurrent computing systems, communication between the concurrent components is hidden from the programmer (e.g., by using futures), while in others it must be handled explicitly. Explicit communication can be divided into two classes:
Shared memory communication Concurrent components communicate by altering the contents of shared memory locations (exemplified by Java and C#). This style of concurrent programming usually requires the application of some form of locking (e.g., mutexes, semaphores, or monitors) to coordinate between threads.
Message passing communication Concurrent components communicate by exchanging messages (exemplified by Erlang and occam). The exchange of messages may be carried out asynchronously, or may use a rendezvous style in which the sender blocks until the message is received. Asynchronous message passing may be reliable or unreliable (sometimes referred to as "send and pray"). Message-passing concurrency tends to be far easier to reason about than shared-memory concurrency, and is typically considered a more robust form of concurrent programming. A wide variety of mathematical theories for understanding and analyzing message-passing systems are available, including the Actor model, and various process calculi. Message passing can be efficiently implemented on symmetric multiprocessors, with or without shared coherent memory.
Shared memory and message passing concurrency have different performance characteristics; typically (although not always), the per-process memory overhead and task switching overhead is lower in a message passing system, but the overhead of message passing itself is greater than for a procedure call. These differences are often overwhelmed by other performance factors. The piece above says that asynchronous communications can be unreliable, but that can be avoided by using a transactional queuing system (JMS over MQSeries, OpenMQ, etc ...)
My two cents worth.
The two paradigms do not compete they are different in purpose, We are talking asynchronous vs synchronous communications. For scalability it is usually best to do asynchronous whenever possible, since you can always defer to another process or process the results whenever you have extra bandwidth. It is just not always possible to split algorithms into asynchronous pieces of work.