Haskell 用于服务器？答案

【问题标题】：Haskell for a server?Haskell 用于服务器？
【发布时间】：2010-09-28 12:31:37
【问题描述】：

关于制作游戏服务器，Erlang 似乎总是作为一种具有可扩展性和并发特性的“为这类事物而构建”的语言出现。我在 Haskell 和 Erlang 方面都没有经验，但从表面上看，它们似乎是一样的。查看 Haskell 的文档，它似乎支持多处理器可扩展性和并发性，据说 Haskell 是一种更可靠的语言，并且拥有一个明显更好的社区。那么，我的问题是，Haskell 是否被认为是像 Erlang 所认为的那样出色的服务器构建解决方案？

【问题讨论】：

Haskell 诞生于网络之前。电信公司的 Erlang。
Haskell 是在 1990 年定义的。C++ 也是由一家电信公司设计的。
code.facebook.com/posts/745068642270222/…

标签： haskell erlang

【解决方案1】：

我相信你能找到这样想的人，但我认为你对 Erlang 支持这种使用的能力是错误的；它广泛用于电话应用程序，实际上非常强大。 Erlang 针对高度可靠、高并发的服务器进行了非常优化。

【讨论】：

我想我对你的回复有点困惑——你开始说我弄错了 Erlang 可以用于制作游戏服务器之类的东西，然后你说它经过优化处理可靠的并发服务器？

【解决方案2】：

Haskell 是否与 Erlang 一样好取决于人们对一门语言的需求。我认为两者都可以作为游戏服务器做得很好，但这主要取决于您想要或期望从编程语言中获得什么。最容易注意到的区别之一是 Haskell 是一种具有类型推断的静态类型语言，而 Erlang 是一种动态类型语言。总的来说，我想说 Haskell 对那些不习惯函数式编程的人来说需要更多的“复杂性”。

【讨论】：

【解决方案3】：

这取决于你想用你的服务器做什么。正如电信应用程序所期望的那样，Erlang 擅长以非常高的并发性执行简单任务。如果您的服务器每秒或一次需要大量连接，Erlang 是您的朋友。 Erlang 还为在多个服务器上分配负载提供了更好的支持。

Haskell 擅长复杂的符号计算，截至 2009 年 4 月，它还可以处理大量线程（请参阅下面的更新）。此外，Haskell 有更多用于正确处理复杂代码的工具：诸如QuickCheck、SmallCheck 和静态类型系统。因此，如果您的服务器正在做复杂而有趣的事情，而您只需要一台服务器就可以过关，那么使用 Haskell 可能会更好。

2009 年 4 月 13 日更新：可靠消息来源 Don Stewart 报告说“Glasgow Haskell 编译器中的最后一个线程缩放错误在几个月前就已经解决了”，并且一些用户报告使用一百万个 Haskell 线程没有麻烦。截至 2009 年 1 月，有一个 new, unpublished paper from the implementors 可以描述如何实现这一目标。

2012 年 2 月 21 日更新：John Hughes 的公司 QuviQ 现在为 Erlang 开发 QuickCheck。他们发现了许多非常有趣的错误。您可以免费下载“QuickCheck Mini”；它与 Haskell QuickCheck 相当。还有更强大的商业版本。

【讨论】：

你能提供一些证据来证明你关于 Haskell 更快地撞墙的说法吗？使用操作系统线程，也许……但是 Haskell 线程呢？
当我看到这个时，我的 Erlang 泡沫有点破了：nabble.com/Chameneos.rednux-micro-benchmark-td19925134.html ...我在我的盒子上验证了结果，它们是正确的，SMP 可扩展性和消息传递似乎存在一些大问题。 GHC 实现的性能要好得多...
@ja：我所有的证据都来自与 ICFP (icfpconference.org) 的 Erlang 和 GHC 人员的走廊对话。的确，去年 GHC 的人确实在为多核和并行性做准备，而我的印象是 Erlang 现在更多地处于商业化阶段。
GHC 的最后一个 (?) 线程扩展问题在几个月前就已经解决了，并且有几份报告称数百万多个线程没有问题。也就是说，Erlang 的重点更多地放在分发上，而不是共享内存多核。
我想我应该指出的是，Erlang 也有 Quickcheck，它甚至比 Haskell 版本还要进化一些。 Erlang QC 和 Haskell QC 都是由同一个人制作的，但 EQC 现在甚至已经商业化。

【解决方案4】：

我上次查看时，在 Erlang 中构建可扩展服务器的库和框架看起来比在 Haskell 中的要成熟一些。我建议查看Programming Erlang: Software for a Concurrent World 以获取有关这些信息。

【讨论】：

【解决方案5】：

这些论文的基准表明 Haskell 可以与 Apache 竞争：

Developing a high-performance web server in Concurrent Haskell
——西蒙·马洛

Combining Events And Threads For Scalable Network Services: Implementation And Evaluation Of Monadic, Application-level Concurrency Primitives
— Peng Li Stephan A. Zdancewic（见图 19）

【讨论】：

不幸的是，Marlow 的论文不再公开

【解决方案6】：

由于惰性，在 Haskell 应用程序中引入内存泄漏要容易得多。长时间运行的服务器准确地说是那种你真的不希望有任何内存泄漏的程序。

虽然我同意 Haskell 是一种更可靠且更易于编程的语言，但 Erlang 更容易，并且有许多专门用于此类用途的库。

我认为没有与 Mnesia 等价的 Haskell，而且编写它会很困难。您可以编写 gen_server、gen_event 等的 Haskell 版本，但它们不会经过十多年的优化和调整。

【讨论】：

实际上，如果不使用 FFI 或类似的东西，内存泄漏是不可能引入的：所有内存都由垃圾收集器负责并且可以回收。您指的是“空间泄漏”，这意味着用于未评估的thunk 的内存。仅评估它们（或丢弃它们）将释放内存。也就是说，处理这个问题，因为它对大多数程序员来说完全陌生，一开始需要大量的工作，你应该为此做好计划。
Curt 绝对正确，空间泄漏在技术上与内存泄漏不同，但在许多无限迭代的程序中它们的行为方式相同。我想说的是，在 Haskell 程序中无意中引入空间泄漏比在 C 程序中引入内存泄漏要容易得多，因为它需要仔细注意惰性求值顺序，这通常是不直观的。这就是说我是 Haskell 菜鸟——我想通过练习会变得更容易。

【解决方案7】：

我在 Haskell 和 Erlang 方面都没有经验，但从表面上看，它们似乎是一样的。

Haskell 和 Erlang 之间有一些非常明显的区别。 Erlang 是专门为并发系统设计的。语言和虚拟机都被设计成支持很多很多的进程，Erlang 使用一个actor风格的系统来管理它们之间的通信。 Haskell 也很容易支持并发，因为它的函数性质，但是在 Haskell 中进行并发编程仍然有点困难，并且语言没有专门设置来促进这一点。

与 Haskell 一样，Erlang 不会在进程之间共享状态，因此很容易编写多进程软件。但是 Haskell 和 Erlang 的编程风格有点不同，因为 Erlang 强调使用小进程来执行并发处理。

我喜欢 Haskell——它是我最喜欢的语言之一——但如果我要编写服务器软件，我可能会使用 Erlang。但如果您更了解 Haskell 或发现库支持更出色，当然可以在 Haskell 中编写服务器。

【讨论】：

> 它实际上是一种逻辑编程语言不，它不是。没有内置搜索，您不能使用未初始化的变量，没有完全统一等。语法是 Prolog-ish，并且模式匹配允许在左侧使用相同的变量（而不是在右侧！），但它很实用。

【解决方案8】：

现在有一个新选项：use the Haskell/Erlang FFI to write your logic in Haskell and communicate using Erlang。

【讨论】：