ruby-on-rails-3 - 为什么 Rails 不完全支持开箱即用地编写事件代码

Question

Node.js 出现后，它是普及事件编程的一件事。但是，Ruby 确实有支持编写事件代码的 EventMachine。

在 Rails 中支持事件的要求是:
1. 运行 react 器的事件服务器(瘦，彩虹)
2. Fibers (Ruby 1.9.3) 为了让编写事件代码更容易，否则我们可以使用线程。
3. 所有 gems 事件(例如 mysql2)。

Nodejs 展示了事件编程的明显好处。那么为什么 Rails 社区不采用 eventmachine 呢？我认为 rails 不能完全移植到 eventmachine 的原因之一是因为依赖于可能无法触发的底层 gem。但是有谁知道是否有朝那个方向迈进的计划？

Rails 可以做 Nodejs 所做的事情，但 Nodejs 一开始就提倡对所有库制造商进行事件编程，因此按照惯例，您添加到 node 中的 package.json 的大多数依赖项，您都知道它将被事件处理并且可以使用nodejs 开箱即用。

Answer 1

最大的原因是 Rails 生态系统不是为事件 IO 构建的，在应用程序中引入单个非事件 IO 会消除好处。用 Ruby(和 Rails)编写事件代码是很有可能的，但这并不一定是直截了当的，因为 gem 何时执行或不执行事件 IO 并不总是很清楚，并且开发人员需要花费大量时间追查应用程序可能阻塞的位置。相比之下，Node 是在 IO 永远不应该是同步的隐含理想下创建的，其整个生态系统都源于该理想，这意味着开发人员不必担心他们的 IO 操作是否将是同步的或不;默认情况下它们是异步的。

此外，事件 Web 应用程序仅在您受 IO 限制时才真正有用。如果您的应用程序受 CPU 限制，或者正在执行繁重的同步 CPU 工作，那么事件模型可能不是正确的方法。 Ruby 可能需要大量 CPU，这主要是由于该语言的元编程结构和垃圾收集器(在 Ruby 2.1 中应该会大大改进!)，这可能使它不如 Node 适合事件编程。

Rails 有许多可用的并发模型 - fork 、抢占式线程和事件处理 - 开发人员可以选择最适合其应用领域的模型。 Forking 是默认设置，因为它很简单，不需要任何特殊考虑(只要您在 POSIX 系统上部署!)，并且在创建 Rails 时 Ruby 没有系统线程。现在，有了 Ruby 1.9+(系统线程，GIL)和 JRuby(没有 GIL!)，线程代码很容易部署。 Ruby 2.0 带来了对 COW 友好的垃圾收集器，这意味着 fork 也比以前更有效率。

归根结底，事件代码并不是默认的，因为它需要开发人员做更多的工作，而且对于许多人来说，默认的 fork 模型已经足够好了。如果不是这样，开发人员可以选择线程或事件代码，以最适合他们的基础架构和应用程序域。