混合Erlang和Haskell
如果你已经购买了函数式编程范例，那么你很可能喜欢Erlang和Haskell。 两者都具有纯粹的功能内核和其他优点，例如轻量级线程，使其非常适合多核世界。 但也有一些不同之处。
Erlang是经过商业验证的具有成熟分布模型的容错语言。 它具有看似独特的功能，能够通过热代码加载在运行时升级其版本。 （很酷！）
另一方面，Haskell具有任何主流语言中最复杂的类型系统。 （我将'主流'定义为任何具有已发表的O'Reilly书籍的语言，因此哈斯克尔很重要。）其直线单线程性能优于Erlang，轻量级线程看起来更轻。
我正在尝试为我的其余编码生活组建一个开发平台，并且想知道是否可以将Erlang和Haskell混合在一起来实现最佳的平台。 这个问题有两个部分：
请回答任何经验（积极或消极），想法或建议。 实际上，欢迎任何反馈（缺少直接滥用！）。
更新
感谢所有4个回复日期 - 每个教我至少一个我不知道的有用的东西。
关于编码生活的其余部分 - 我把它放在脸颊上以引发争论，但事实上它确实如此。 我有一个项目，我打算继续努力，直到我死去，并且需要一个稳定的平台。
在我上面提出的平台中，我只会编写Haskell，因为Erlang将自动生成样板文件。 那么Haskell会持续多久？ Lisp仍然和我们在一起，看起来不会很快就会消失。 Haskell是BSD3的开源代码，已经达到了临界质量。 如果编程本身还有50年的时间，我希望Haskell或者Haskell的一些持续发展仍然会在这里。
回复rvirding的帖子更新2
同意 - 实施一个完整的“Erskell / Haslang”通用虚拟机可能不是绝对不可能的，但它肯定会非常困难。 虽然只是将垃圾收集器级别分享为虚拟机，但仍然困难，但对我而言听起来要难一些。 在垃圾收集模型中，函数式语言必须具有很多共同点 - 不可变数据（包括thunk）的普遍性以及对非常快速分配的要求。 因此，通用性与单片虚拟机紧密捆绑的事实似乎有点奇怪。
虚拟机确实有助于实现临界质量。 只要看看F＃和Scala等“精简”功能语言是如何起飞的。 Scala可能没有Erlang的绝对容错能力，但它为与JVM绑定的很多人提供了一条逃生路线。
虽然单个堆使消息传递速度非常快，但它引入了许多其他问题，主要是GC做得更加困难，因为它必须是交互式的，并且是全局无中断的，因此您不能使用与每个堆一样简单的算法，过程堆模型。
绝对的，这对我来说非常合理。 GHC开发团队中非常聪明的人似乎试图用一个平行的“停止世界”GC来解决部分问题。
http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf
（显然，“停止世界”对于普通的Erlang来说不会因为它的主要用例而飞）。但是即使在“停止世界”的情况下，它们的加速似乎并不普遍。 所以我同意你的观点，不太可能存在一个普遍最好的GC，这就是我在我的问题的第1部分中指定的原因。
GHC运行时可以配置为仅使用一个核心，或者本地机器上的所有核心，或两者之间的任何组合。
这样，对于给定的用例，我可以在基准测试后选择使用Erlang方式，并且运行一个GHC运行时（使用单线程GC）以及每个内核一个Erlang进程，并让Erlang在内核之间复制内存以获得良好的本地化。
或者，在双处理器机器上，每个处理器具有4个内核，处理器上具有良好的内存带宽，基准测试可能表明我运行了一个GHC运行时（使用并行GC），另外每个处理器运行一个Erlang进程。
在这两种情况下，如果Erlang和GHC可以共享一个堆，那么共享可能会被绑定到在单个内核上运行的单个操作系统线程。 （我在这里摆脱了我的深度，这就是为什么我问这个问题。）
我还有另一个议程 - 独立于GC的基准功能语言。 我经常读到OCaml v GHC v Erlang v的基准测试结果，并想知道不同的GC有多混淆结果。 如果GC的选择可以与功能语言的选择正交，那该怎么办？ 无论如何，GC有多昂贵？ 看到这个魔鬼提倡博客文章
http://john.freml.in/garbage-collection-harmful
由我的Lisp朋友约翰弗里姆林，他迷人地给了他的职位标题“自动垃圾收集是垃圾”。 当约翰宣称GC很慢并且没有真正加速那么多时，我希望能够反击一些数字。
许多Haskell和Erlang人都对Erlang监督分布的模型感兴趣，而Haskell同时运行共享内存节点来完成所有数字运算/逻辑。
一开始是haskell-erlang库：http://hackage.haskell.org/package/erlang
我们在Ruby地区通过Hubris也有类似的努力：http://github.com/mwotton/Hubris/tree/master
现在的问题是找到一个人真正推动Erlang / Haskell互操作来找出棘手的问题。
虽然这是一个相当古老的主题，但如果读者仍然感兴趣，那么值得看看Cloud Haskell，它将Erlang风格的并发和分布带入GHC稳定版。
即将推出的分布式进程平台库增加了对OTP类型构造的支持，如gen_servers，监督树和Erlang / OTP借鉴和启发的各种其他“haskell风格”抽象。
你可以使用一个OTP gen_supervisor进程来监视你用open_port（）产生的Haskell实例。 根据“端口”退出的方式，您可以重新启动它，或者确定它是故意停止并让相应的Erlang进程死掉。
Fugheddaboudit。 即使这些与语言无关的虚拟机有时也会在语言间传递数据时遇到麻烦。 你应该在两者之间序列化数据：数据库，XML-RPC，类似的东西。
顺便说一句，在你的余生中单一平台的想法也可能不切实际。 计算技术和时尚变化太频繁，以至于你不能永远只用一种语言。 你的问题指出了这一点：即使在今天，没有一种语言能做到我们所希望的一切。
链接地址: http://www.djcxy.com/p/7477.html上一篇: Mixing Erlang and Haskell
下一篇: GHC optimization