问题描述
我一直在观察功能编程语言和功能的可见性一段时间。我看着他们，没有看到上诉的理由。
I have been watching the growing visibility of functional programming languages and features for a while. I looked into them and didn't see the reason for the appeal.
然后，最近我参加了Kevin Smith的Erlang基础演讲，在。
Then, recently I attended Kevin Smith's "Basics of Erlang" presentation at Codemash.
我喜欢演示文稿，并了解到功能编程的许多属性使得更容易避免线程/并发问题。我明白缺少状态和可变性使得多线程不可能改变相同的数据，但凯文说（如果我理解正确），所有的通信都是通过消息进行的，并且同步处理消息（再次避免并发问题）。
I enjoyed the presentation and learned that a lot of the attributes of functional programming make it much easier to avoid threading/concurrency issues. I understand the lack of state and mutability makes it impossible for multiple threads to alter the same data, but Kevin said (if I understood correctly) all communication takes place through messages and the mesages are processed synchronously (again avoiding concurrency issues).
但是我已经看到，Erlang用于高度可扩展的应用程序（爱立信首先创建它的全部原因）。如果一切都被处理为同步处理的消息，那么如何才能高效地处理数千个请求？这不是为什么我们开始转向异步处理 - 所以我们可以利用同时运行多个操作线程并实现可扩展性？似乎这样的架构，虽然更安全，但在可扩展性方面却是倒退一步。我缺少什么？
But I have read that Erlang is used in highly scalable applications (the whole reason Ericsson created it in the first place). How can it be efficient handling thousands of requests per second if everything is handled as a synchronously processed message? Isn't that why we started moving towards asynchronous processing - so we can take advantage of running multiple threads of operation at the same time and achieve scalability? It seems like this architecture, while safer, is a step backwards in terms of scalability. What am I missing?
我了解Erlang的创建者有意避免支持线程以避免并发问题，但我认为多线程是实现可扩展性所必需的。
I understand the creators of Erlang intentionally avoided supporting threading to avoid concurrency problems, but I thought multi-threading was necessary to achieve scalability.
功能编程语言如何固有线程安全，但仍然扩展？
推荐答案
功能语言（通常）不依赖变量变量。因此，我们不必保护变量的共享状态，因为该值是固定的。这反过来又避免了传统语言通过跨越处理器或机器实现算法的大多数跳跃。
A functional language doesn't (in general) rely on mutating a variable. Because of this, we don't have to protect the "shared state" of a variable, because the value is fixed. This in turn avoids the majority of the hoop jumping that traditional languages have to go through to implement an algorithm across processors or machines.
Erlang比传统的功能语言更进一步在一个消息传递系统中烘烤，允许所有操作在基于事件的系统上，其中一条代码仅仅担心接收消息和发送消息，而不用担心更大的图像。
Erlang takes it further than traditional functional languages by baking in a message passing system that allows everything to operate on an event based system where a piece of code only worries about receiving messages and sending messages, not worrying about a bigger picture.
这意味着程序员（名义上）不关心消息将在另一台处理器或机器上处理：简单地发送消息足以使其继续。如果它关心响应，它将等待另一个消息。
What this means is that the programmer is (nominally) unconcerned that the message will be handled on another processor or machine: simply sending the message is good enough for it to continue. If it cares about a response, it will wait for it as another message.
最终的结果是每个代码段都是独立于每个其他代码段。没有共享代码，没有共享状态和来自一个消息系统的所有交互，可以在许多硬件（或不）之间分发。
The end result of this is that each snippet is independent of every other snippet. No shared code, no shared state and all interactions coming from a a message system that can be distributed among many pieces of hardware (or not).
与传统系统对比：我们必须在受保护变量和代码执行周围放置互斥量和信号量。我们通过堆栈在函数调用中有紧密的绑定（等待返回发生）。所有这些都会产生瓶颈，这在像Erlang这样的共享系统中不成问题。
Contrast this with a traditional system: we have to place mutexes and semaphores around "protected" variables and code execution. We have tight binding in a function call via the stack (waiting for the return to occur). All of this creates bottlenecks that are less of a problem in a shared nothing system like Erlang.
编辑：我还应该指出，Erlang是异步的。你发送你的消息，也许/有一天，另一个消息回来。或不。
I should also point out that Erlang is asynchronous. You send your message and maybe/someday another message arrives back. Or not.
斯宾塞关于无序执行的观点也很重要，并得到很好的回答。
Spencer's point about out of order execution is also important and well answered.
这篇关于功能语言（特别是Erlang）如何/为什么规模很大？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！