具有“消息传递/共享状态”；困境（并发和分布）以“圣战”的形式出现？
我不太了解关于哪种模型更好的讨论状况，所以我想问一个非常直接的问题：看起来两种对立的观点确实存在激烈的争论吗？例如，像基于原型/类的 OOP 或动态与静态类型
（虽然这些确实不是很合适的例子，我只是不知道如何更清楚地表达我的问题）
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)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
来自 Wikipedia
在某些并发计算系统中，并发组件之间的通信对程序员是隐藏的（例如，通过使用 futures），而在其他情况下则必须明确处理。显式通信可以分为两类：
共享内存通信
并发组件通过更改共享内存位置的内容进行通信（以 Java 和 C# 为例）。这种并发编程风格通常需要应用某种形式的锁定（例如，互斥体、信号量或监视器）来在线程之间进行协调。
消息传递通信
并发组件通过交换消息进行通信（例如 Erlang 和 occam）。消息的交换可以异步地进行，或者可以使用会合方式，其中发送者阻塞直到接收到消息。异步消息传递可能是可靠的，也可能是不可靠的（有时称为“发送并祈祷”）。消息传递并发性往往比共享内存并发性更容易推理，并且通常被认为是一种更健壮的并发编程形式。有多种数学理论可用于理解和分析消息传递系统，包括 Actor 模型和各种过程演算。消息传递可以在对称多处理器上有效地实现，无论有或没有共享一致内存。
共享内存和消息传递并发具有不同的性能特征；通常（尽管并非总是），消息传递系统中的每进程内存开销和任务切换开销较低，但消息传递本身的开销大于过程调用的开销。这些差异常常被其他性能因素所掩盖。上面的文章说异步通信可能不可靠，但是可以通过使用事务排队系统（MQSeries 上的 JMS、OpenMQ 等...）来避免这种情况
我的两美分价值。
这两种范例并不竞争，它们的目的不同，我们正在讨论异步通信与同步通信。为了可扩展性，通常最好尽可能进行异步，因为只要有额外的带宽，您就可以始终推迟到另一个进程或处理结果。只是并不总是可以将算法分解为异步工作。
From Wikipedia
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.