我相信 Erlang 社区并不羡慕 Node.js,因为它本身就提供非阻塞 I/O,并且可以轻松地将部署扩展到多个处理器(Node.js 中甚至没有内置的东西)。更多详情请访问http://journal.dedasys.com/2010/04/29/erlang-vs-node- js和Node.js 或 Erlang
哈斯克尔呢?Haskell 能否提供 Node.js 的一些好处,即无需求助于多线程编程即可避免阻塞 I/O 的干净解决方案?
Node.js 有很多吸引人的地方
好的,所以看了一点 @gawi 指出的node.js 演示文稿,我可以多说一点 Haskell 与 node.js 的比较。在演示文稿中,Ryan 描述了 Green Threads 的一些好处,但接着说他并不认为缺少线程抽象是一个缺点。我不同意他的立场,尤其是在 Haskell 的上下文中:我认为线程提供的抽象对于使服务器代码更容易正确和更健壮至关重要。尤其是:
每个连接使用一个线程可以让您编写表达与单个客户端通信的代码,而不是编写同时处理 所有 客户端的代码。可以这样想:使用线程处理多个客户端的服务器看起来与处理单个客户端的服务器几乎相同;主要区别在于fork前者有一个地方。如果您要实现的协议非常复杂,那么同时为多个客户端管理状态机会变得非常棘手,而线程让您只需编写与单个客户端的通信即可。代码更容易正确,更容易理解和维护。
fork
单个操作系统线程上的回调是协作多任务处理,而不是抢占式多任务处理,这是线程所获得的。协作多任务的主要缺点是程序员负责确保没有饥饿。它失去了模块化:在一个地方犯了一个错误,它可能会搞砸整个系统。这确实是您不想担心的事情,抢占是简单的解决方案。此外,回调之间的通信是不可能的(它会死锁)。
并发在 Haskell 中并不难,因为大多数代码都是纯代码,因此在构造上是线程安全的。有简单的通信原语。在 Haskell 中使用并发比使用具有无限制副作用的语言更难自爆。