Node.js 出现后，它是普及事件编程的一件事。但是，Ruby 确实有支持编写事件代码的 EventMachine。
在 Rails 中支持事件的要求是：
1. 运行反应器的事件服务器（瘦，彩虹）
2. Fibers（Ruby 1.9.3）为了使编写事件代码更容易，否则我们可以使用线程。
3. 所有 gems 事件（例如 mysql2）。
Nodejs 展示了事件编程的明显好处。那么为什么 Rails 社区不采用 eventmachine 呢？我认为 rails 不能完全移植到 eventmachine 的原因之一是因为依赖于可能无法触发的底层 gem。但是有谁知道是否有朝那个方向迈进的计划？
Rails 可以做 Nodejs 所做的事情，但 Nodejs 一开始就提倡对所有库制造商进行事件编程，因此按照惯例，您添加到 node.json 中的大多数依赖项，您都知道它将被事件处理，并且可以与 nodejs 一起工作。盒子。
最大的原因是 Rails 生态系统不是为事件 IO 构建的，在您的应用程序中引入单个非事件 IO 会消除好处。用 Ruby（和 Rails）编写事件代码是很有可能的，但这并不一定是直截了当的，因为 gem 何时执行或不执行事件 IO 并不总是很清楚，并且开发人员需要花费大量时间追查应用程序可能阻塞的位置。相比之下，Node 是在 IO 永远不应该是同步的隐含理想中创建的，它的整个生态系统都是从这个理想出发的，这意味着开发人员不必担心他们的 IO 操作是否会同步或不; 默认情况下假设它们是异步的。
此外，事件 Web 应用程序仅在您受 IO 限制时才真正有用。如果您的应用程序受 CPU 限制，或者正在执行繁重的同步 CPU 工作，那么事件模型可能不是正确的方法。Ruby 可能需要大量的 CPU，这主要是由于该语言的元编程结构和垃圾收集器（在 Ruby 2.1 中应该会大大改进！），这可能使其不如 Node 适合事件编程。
Rails 有许多可用的并发模型 - 分叉、抢占式线程和事件 - 开发人员可以选择最适合他们的应用程序域的一种。Forking 是默认设置，因为它很简单，不需要任何特殊考虑（只要您在 POSIX 系统上进行部署！），并且在创建 Rails 时 Ruby 没有系统线程。现在，有了 Ruby 1.9+（系统线程，GIL）和 JRuby（没有 GIL！），线程代码很容易部署。Ruby 2.0 带来了对 COW 友好的垃圾收集器，这意味着分叉也比以前更有效率。
归根结底，事件代码并不是默认的，因为它需要开发人员做更多的工作，而且对于许多人来说，默认的分叉模型已经足够好了。在不是的情况下，开发人员可以选择线程或事件代码，因为它最适合他们的基础设施和应用程序域。