multithreading - Haskell 对 Node.js 的响应是什么？

Question

我相信 Erlang 社区并不羡慕 Node.js，因为它本身就提供非阻塞 I/O，并且可以轻松地将部署扩展到多个处理器(Node.js 中甚至没有内置的东西)。更多详情请访问 http://journal.dedasys.com/2010/04/29/erlang-vs-node-js和 Node.js or Erlang

Haskell 呢？ Haskell 能否提供 Node.js 的一些好处，即无需求助于多线程编程即可避免阻塞 I/O 的干净解决方案？

---

Node.js 有很多吸引人的地方

1. 事件:无线程操作，程序员只提供回调(如在 Snap 框架中)
2. 回调保证在单线程中运行:不可能出现竞争条件。
3. 漂亮而简单的 UNIX 友好 API。奖励:出色的 HTTP 支持。 DNS 也可用。
4. 默认情况下，每个 I/O 都是异步的。这使得更容易避免锁定。但是，回调中过多的 CPU 处理会影响其他连接(在这种情况下，应将任务拆分为更小的子任务并重新调度)。
5. 客户端和服务器端使用相同的语言。 (不过，我看不出这个有太多值(value)。jQuery 和 Node.js 共享事件编程模型，但其余的却非常不同。我只是看不出如何在服务器端和客户端之间共享代码在实践中很有用。)
6. 所有这些都封装在一个产品中。

Answer 1

好的，看了一点node.js presentation @gawi 指出我，我可以多说一点 Haskell 与 node.js 的比较。在演示文稿中，Ryan 描述了 Green Threads 的一些好处，但接着说他并不认为缺少线程抽象是一个缺点。我不同意他的立场，尤其是在 Haskell 的上下文中:我认为线程提供的抽象对于使服务器代码更容易正确和更健壮至关重要。特别是:

• 每个连接使用一个线程可以让您编写表达与单个客户端通信的代码，而不是编写同时处理所有个客户端的代码。可以这样想:使用线程处理多个客户端的服务器看起来与处理单个客户端的服务器几乎相同；主要区别在于前者的某处有一个 fork 。如果您正在实现的协议(protocol)非常复杂，同时为多个客户端管理状态机会变得非常棘手，而线程让您只需编写与单个客户端的通信即可。代码更容易正确，也更容易理解和维护。

• 单个操作系统线程上的回调是协作多任务处理，而不是抢占式多任务处理，这是线程所获得的。协作多任务的主要缺点是程序员负责确保没有饥饿。它失去了模块化:在一个地方犯了一个错误，它可能会搞砸整个系统。这确实是您不想担心的事情，抢占是简单的解决方案。此外，回调之间的通信是不可能的(它会死锁)。

• 在 Haskell 中并发并不难，因为大多数代码都是纯代码，因此在构造上是线程安全的。有简单的通信原语。在 Haskell 中使用并发比使用具有无限制副作用的语言更难自爆。