我相信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有很多吸引人的地方
事件:无线程操作，程序员仅提供回调(如Snap框架中一样)回调保证在单个线程中运行:不可能出现竞争条件。 漂亮又简单的UNIX友好API。奖励:出色的HTTP支持。 DNS也可用。 默认情况下，每个I / O都是异步的。这样可以更轻松地避免锁定。但是，回调中过多的CPU处理会影响其他连接(在这种情况下，任务应拆分为较小的子任务并重新计划)。 客户端和服务器端使用相同的语言。 (但是，我认为这一点没有太大值(value)。jQuery和Node.js共享事件编程模型，但其余部分却大不相同。我只是看不到如何在服务器端和客户端之间共享代码。在实践中很有用。)所有这些都打包在一个产品中。 好的，因此，在观看了@gawi指向我的node.js presentation内容后，我可以进一步说明Haskell与node.js的比较。在演示中，Ryan描述了Green Threads的一些好处，但是接着说，他并不认为缺少线程抽象并不是一个缺点。我不同意他的立场，尤其是在Haskell的情况下:我认为线程提供的抽象对于使服务器代码更容易正确，更健壮至关重要。尤其是:
每个连接使用一个线程，使您可以编写代码来表示与单个客户端的通信，而不是编写同时处理所有客户端的代码。可以这样想:一台处理带有线程的多个客户端的服务器看起来与处理一个客户端的服务器几乎相同；主要区别在于前者中的某个地方有一个fork。如果您要实现的协议(protocol)非常复杂，则同时管理多个客户端的状态机将变得非常棘手，而线程使您仅可以编写与单个客户端的通信脚本。该代码更容易正确使用，也易于理解和维护。 单个OS线程上的回调是协作式多任务处理，而不是抢先式多任务处理，这是线程获得的功能。协作式多任务处理的主要缺点在于，程序员负责确保没有饥饿。它失去了模块化:在一个地方犯一个错误，它会破坏整个系统。这确实是您不需要担心的事情，而抢占是简单的解决方案。而且，回调之间的通信是不可能的(这将导致死锁)。 在Haskell中并发并不困难，因为大多数代码是纯净的，因此在构造上是线程安全的。有简单的通信原语。与使用无限制副作用的语言相比，在Haskell中并发射击自己要困难得多。