如果您已经接受了函数式编程范例，那么您很可能喜欢Erlang和Haskell。两者都具有纯函数核心和其他优点，例如轻量级线程，使它们非常适合多核世界。但也存在一些差异。
Erlang是一种商业上成熟的容错语言，具有成熟的分布式模型。它似乎具有一项独特的功能，即通过热代码加载在运行时升级其版本。（太酷了！）
另一方面，Haskell拥有任何主流语言中最复杂的类型系统。（我将“主流”定义为任何具有O'Reilly出版书的语言，因此Haskell也算。）其直线单线程性能看起来优于Erlang，并且其轻量级线程看起来更轻盈。
我正在尝试组建一个开发平台，以用于我的余生编码，并想知道是否可以混合使用Erlang和Haskell来实现最佳平台。这个问题有两个部分：
虽然具有单个堆使消息传递非常快，但它引入了许多其他问题，主要是由于它必须是交互式的和全局不可中断的，因此进行GC变得更加困难，因此无法使用与每个进程堆模型相同的简单算法。
当然，这对我来说很有道理。 GHC开发团队中非常聪明的人似乎正在尝试使用并行“停止世界”GC解决部分问题。
GHC运行时可以配置为仅使用一个核心，或者使用本地计算机上的所有核心，或者介于两者之间的任何组合。因此，在给定的用例中，经过基准测试后，我可以选择走Erlang的路线，每个核心运行一个GHC运行时（带有单线程GC）加上一个Erlang进程，并让Erlang在核心之间复制内存以获得良好的局部性。
另外，在具有良好处理器内存带宽的双处理器机器上，基准测试可能表明我应该在每个处理器上运行一个GHC运行时（带有并行GC），加上一个Erlang进程。
在两种情况下，如果Erlang和GHC可以共享堆，则共享可能会绑定到以某种方式在单个核心上运行的单个OS线程。（我已经超出了我的能力范围，这就是我问问题的原因。）
我还有另一个议程-独立于GC对功能语言进行基准测试。通常我会阅读OCaml v GHC v Erlang v ...的基准测试结果，并想知道这些结果被不同的GC所混淆了多少。如果GC的选择与功能语言的选择是正交的，那么GC有多昂贵？请参见这篇魔鬼倡导者的博客文章。
Erlang是一种商业上成熟的容错语言，具有成熟的分布式模型。它似乎具有一项独特的功能，即通过热代码加载在运行时升级其版本。（太酷了！）
另一方面，Haskell拥有任何主流语言中最复杂的类型系统。（我将“主流”定义为任何具有O'Reilly出版书的语言，因此Haskell也算。）其直线单线程性能看起来优于Erlang，并且其轻量级线程看起来更轻盈。
我正在尝试组建一个开发平台，以用于我的余生编码，并想知道是否可以混合使用Erlang和Haskell来实现最佳平台。这个问题有两个部分：
- 我希望使用Erlang作为一种容错MPI将GHC运行时实例粘合在一起。每个GHC运行时将有一个Erlang进程。如果“不可能发生的事情”发生了，GHC运行时就会死亡，然后Erlang进程会以某种方式检测到并死亡。Erlang的热代码加载和分发功能将继续工作。可以配置GHC运行时仅使用一个核，或者使用本地计算机上的所有核心，或者两者之间的任何组合。一旦编写了Erlang库，Erlang级别的其余代码应该是纯样板文件，并且应根据每个应用程序自动生成。(例如，通过Haskell DSL)如何实现至少其中一些内容？
- 我希望Erlang和Haskell能够共享相同的垃圾收集器。(这比1要远得多。)在JVM和CLR上运行的语言通过共享运行时实现更大的规模。我了解在JVM或CLR上运行Erlang(热代码加载)和Haskell(高阶多态性)存在技术限制。但是仅取消捆绑垃圾收集器怎么样呢？(有点像函数式语言的运行时的开始。)分配显然仍然需要非常快，因此可能需要将其静态链接。并且应该有一些机制来区分可变堆和不可变堆(包括惰性写入一次内存)，因为GHC需要这样做。是否可以修改HIPE和GHC，使垃圾收集器可以共享堆？
请回答任何经验(积极或消极)、想法或建议。实际上，任何反馈(除了直接的虐待!)都受到欢迎。
更新
感谢迄今为止的4个回复 - 每一个都教给了我至少一个有用的东西，我之前不知道。
关于编程生涯的其他事情 - 我略带调侃地提出这个问题以激发讨论，但实际上是真的。我有一个想法，打算一直工作到死亡，并且它需要一个稳定的平台。
在我提出的平台中，我只会写Haskell，因为Erlang的样板代码将会被自动生成。那么Haskell还能持续多久呢？嗯，Lisp仍然存在，并且看起来它不会很快消失。Haskell是BSD3开源的，并且已经实现了临界质量。如果编程本身在50年后仍然存在，我希望Haskell或者Haskell的某种连续演变仍然会存在。
更新2 回应rvirding的帖子
同意 - 实现完整的"Erskell/Haslang"通用虚拟机可能不是绝对不可能的，但肯定非常困难。仅共享垃圾收集器级别作为类似VM的东西，尽管仍然很难，但对我来说难度要小一个数量级。在垃圾收集模型方面，函数式语言必须具有很多共同点 - 不可变数据（包括thunks）的普及性以及需要非常快速的分配。因此，常见性与单片VM紧密捆绑似乎有点奇怪。
VM可以帮助实现关键的质量，只需看看像F＃和Scala这样的“轻量级”函数语言如何起飞。 Scala可能没有Erlang的绝对容错能力，但它为许多被绑定到JVM的人提供了一条出路。虽然具有单个堆使消息传递非常快，但它引入了许多其他问题，主要是由于它必须是交互式的和全局不可中断的，因此进行GC变得更加困难，因此无法使用与每个进程堆模型相同的简单算法。
当然，这对我来说很有道理。 GHC开发团队中非常聪明的人似乎正在尝试使用并行“停止世界”GC解决部分问题。
http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf
显然，“stop the world”对于一般的Erlang并不适用，因为其主要用例。但即使在“stop the world”可行的用例中，它们的加速效果似乎也不是普遍的。所以我同意你的观点，没有普适最佳GC，这也是我在问题第一部分中指定原因的原因。GHC运行时可以配置为仅使用一个核心，或者使用本地计算机上的所有核心，或者介于两者之间的任何组合。因此，在给定的用例中，经过基准测试后，我可以选择走Erlang的路线，每个核心运行一个GHC运行时（带有单线程GC）加上一个Erlang进程，并让Erlang在核心之间复制内存以获得良好的局部性。
另外，在具有良好处理器内存带宽的双处理器机器上，基准测试可能表明我应该在每个处理器上运行一个GHC运行时（带有并行GC），加上一个Erlang进程。
在两种情况下，如果Erlang和GHC可以共享堆，则共享可能会绑定到以某种方式在单个核心上运行的单个OS线程。（我已经超出了我的能力范围，这就是我问问题的原因。）
我还有另一个议程-独立于GC对功能语言进行基准测试。通常我会阅读OCaml v GHC v Erlang v ...的基准测试结果，并想知道这些结果被不同的GC所混淆了多少。如果GC的选择与功能语言的选择是正交的，那么GC有多昂贵？请参见这篇魔鬼倡导者的博客文章。
http://john.freml.in/garbage-collection-harmful
这篇文章是我的Lisp朋友约翰·弗莱姆林写的，他很巧妙地将其标题定为“自动垃圾回收是垃圾”。当约翰声称垃圾回收很慢并且没有真正加快太多时，我希望能够用一些数字来反驳。