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

我相信Erlang社区不会羡慕Node.js，因为它本身就进行非阻塞I / O，并具有将部署轻松扩展到一个以上处理器（Node.js甚至没有内置的功能）的方法。有关更多详细信息，请访问http://journal.dedasys.com/2010/04/29/erlang-vs-node-js和Node.js或Erlang

那Haskell呢？Haskell是否可以提供Node.js的某些好处，即一种避免使用I / O而不使用多线程编程的干净解决方案？

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

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

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

• 每个连接使用一个线程可使您编写表示与单个客户端进行通信的代码，而不是编写同时处理所有客户端的代码。可以这样想：一台处理带有线程的多个客户端的服务器看起来与处理一个客户端的服务器几乎相同；主要区别在于fork前者中有某个地方。如果您要实现的协议非常复杂，则同时管理多个客户端的状态机将变得非常棘手，而线程使您仅可以编写与单个客户端的通信脚本。该代码更容易正确使用，也易于理解和维护。

• 单个OS线程上的回调是协作式多任务处理，与抢先式多任务处理相反，后者是线程获得的。协作式多任务处理的主要缺点在于，程序员负责确保没有饥饿。它失去了模块化：在一个地方犯一个错误，它会破坏整个系统。这确实是您不需要担心的事情，而抢占是简单的解决方案。而且，回调之间的通信是不可能的（这将导致死锁）。

• 并发在Haskell中并不难，因为大多数代码是纯净的，因此构造时线程安全的。有简单的通信原语。与使用无限制副作用的语言相比，在Haskell中并发地射击自己要困难得多。

Haskell是否可以提供Node.js的某些好处，即一种避免使用I / O而不使用多线程编程的干净解决方案？

是的，实际上事件和线程在Haskell中是统一的。

• 您可以在显式轻量级线程中编程（例如，一台笔记本电脑上有数百万个线程）。
• 要么; 您可以根据可扩展的事件通知以异步事件驱动的样式进行编程。

线程实际上是根据事件来实现的，并跨多个核心运行，具有无缝的线程迁移，具有记录的性能和应用程序。

例如

• 大规模并发工作编排
• 在32或48个内核上扩展的并发收集
• 对多线程/多事件程序进行性能分析和调试的工具支持。
• 高性能事件驱动的Web服务器。
• 有趣的用户：例如高频交易。

在32个内核上并发收集nbody

在Haskell中，您既有事件也有线程，而且所有事件都在后台进行。

阅读描述实现的文章。

首先，我不认为您认为node.js做正确的事情公开了所有这些回调。您最终以CPS（连续传递样式）编写程序，我认为完成该转换应该是编译器的工作。

事件：无线程操作，程序员仅提供回调（如Snap框架中一样）

因此，考虑到这一点，您可以根据需要使用异步样式进行编写，但是这样做会错过以高效的同步样式进行编写的功能，每个请求只有一个线程。Haskell在同步代码方面效率极高，尤其是与其他语言相比时。这是所有的事件。

回调保证在单个线程中运行：不可能出现竞争条件。

您仍然可以在node.js中有一个竞争条件，但这更加困难。

每个请求都在其自己的线程中。当您编写必须与其他线程进行通信的代码时，由于haskell的并发原语，使其变得线程安全非常简单。

漂亮又简单的UNIX友好API。奖励：出色的HTTP支持。DNS也可用。

看看黑客，自己看看。

默认情况下，每个I / O都是异步的（尽管有时这很烦人）。这样可以更轻松地避免锁定。但是，回调中过多的CPU处理会影响其他连接（在这种情况下，任务应拆分为较小的子任务并重新计划）。

您没有此类问题，ghc会将您的工作分配到实际的OS线程中。

客户端和服务器端使用相同的语言。（但是，我认为这一点没有太大价值。JQuery和Node.js共享事件编程模型，但其余部分却大不相同。我只是看不到如何在服务器端和客户端之间共享代码。在实践中很有用。）

Haskell不可能在这里赢球...对吗？再想一想，http://www.haskell.org/haskellwiki/Haskell_in_web_browser。

所有这些都包装在一个产品中。

下载ghc，启动cabal。有一个程序包可以满足您的所有需求。

我个人认为Node.js和带有回调的编程是不必要的低级和不自然的事情。当良好的运行时（例如GHC中找到的运行时）可以为您处理回调并且效率很高时，为什么要使用回调进行编程？

同时，GHC运行时有了很大的改进：它现在具有一个称为MIO的“新IO管理器” ，其中“ M”代表多核。它建立在现有IO管理器的基础上，其主要目标是克服导致4个以上内核性能下降的原因。本文提供的性能数字令人印象深刻。见自己：

使用Mio，Haskell中的实际HTTP服务器可扩展到20个CPU内核，与使用以前版本的GHC的相同服务器相比，可将峰值性能提高到6.5倍。Haskell服务器的延迟也得到了改善：在中等负载下，与以前版本的GHC相比，预期响应时间减少了5.7倍

和：

我们还表明，借助Mio，McNettle（用Haskell编写的SDN控制器）可以有效地扩展到40多个内核，在一台机器上每秒可处理超过2000万个新请求，从而成为所有现有SDN控制器中最快的。

Mio已将其纳入GHC 7.8.1版本。我个人认为这是Haskell性能上的重要一步。比较以前的GHC版本和7.8.1编译的现有Web应用程序的性能将非常有趣。

恕我直言，事件是好的，但通过回调进行编程不是。

使Web应用程序的编码和调试特别特殊的大多数问题来自使它们具有可伸缩性和灵活性的原因。最重要的是HTTP的无状态性质。这增强了可导航性，但是在IO元素（在这种情况下为Web服务器）调用应用程序代码中的不同处理程序时，会带来控制反转。此事件模型（或更准确地说是回调模型）是一场噩梦，因为回调不共享变量范围，并且导航的直观视图也丢失了。防止用户来回导航时所有可能的状态更改以及其他问题非常困难。

可以说问题类似于事件模型可以正常工作的GUI编程，但是GUI没有导航和后退按钮。这增加了Web应用程序中可能的状态转换。试图解决这些问题的结果是重型框架具有复杂的配置，大量的魔术标识符没有引起问题的根源：回调模型及其固有的缺乏可变范围共享的特性，并且没有顺序，因此顺序必须通过链接标识符来构造。

存在基于顺序的框架，例如ocsigen（ocaml）海边（smalltalk）WASH（已停产，Haskell）和mflow（Haskell），这些框架在维持可导航性和REST功能的同时解决了状态管理问题。在这些框架中，程序员可以将导航表示为命令序列，其中程序在单个线程中发送页面并等待响应，变量在范围内，后退按钮自动工作。这样就固有地生成了更短，更安全，更具可读性的代码，其中程序员清楚地看到了导航。（警告：我是mflow的开发人员）

这个问题非常荒谬，因为1）Haskell已经以更好的方式解决了这个问题，并且2）Erlang的方式大致相同。这是针对节点的基准测试：http : //www.yesodweb.com/blog/2011/03/preliminary-warp-cross-language-benchmarks

给Haskell 4个内核，它可以在一个应用程序中每秒处理10万个（简单）请求。Node不能做那么多，也不能跨内核扩展单个应用程序。而且您无需采取任何措施来获得此收益，因为Haskell运行时是非阻塞的。Erlang是运行时内置的非阻塞IO的唯一其他（相对通用）语言。

就像nodejs删除了libev一样 ，Snap Haskell Web框架也删除了libev。