関数型プログラミングのパラダイムに賛同している場合は、ErlangとHaskellの両方が好きである可能性があります。どちらも純粋に機能的なコアと、マルチコアの世界にぴったりの軽量スレッドなどの他の優れた機能を備えています。しかし、いくつかの違いもあります。
Erlangは、成熟した配布モデルを備えた、商業的に証明されたフォールトトレラント言語です。ホットコードの読み込みを介して実行時にバージョンをアップグレードする機能には、一見ユニークな機能があります。（かっこいい！）
一方、Haskellは、主流の言語の中で最も洗練された型システムを備えています。（ここで、「mainstream」をO'Reillyの本が出版されている言語と定義しているので、Haskellは重要です。）その直線的なシングルスレッドのパフォーマンスはErlangよりも優れており、軽量のスレッドもさらに軽く見えます。
私は残りのコーディングライフのために開発プラットフォームをまとめようとしていますが、 ErlangとHaskellを組み合わせて最高のプラットフォームを実現できるかどうか疑問に思っていました。この質問には2つの部分があります。
- Erlangを一種のフォールトトレラントMPIとして使用して、GHCランタイムインスタンスを結合したいと思います。GHCランタイムごとに1つのErlangプロセスがあります。「不可能が起こった」とGHCランタイムが停止した場合、Erlangプロセスはそれを何らかの形で検出して停止します。Erlangのホットコードのロードおよび配布機能は引き続き機能します。GHCランタイムは、1つのコアのみ、ローカルマシン上のすべてのコア、またはそれらの間の任意の組み合わせを使用するように構成できます。Erlangライブラリが作成されたら、残りのErlangレベルのコードは純粋に定型的であり、アプリケーションごとに自動的に生成されます。（たとえば、Haskell DSLによるものかもしれません。）これらのことの少なくともいくつかをどのように達成するのでしょうか？
- ErlangとHaskellが同じガラベージコレクターを共有できるようにしたいと思います。（これは、1よりもはるかに遠い考えです。）JVMおよびCLRで実行される言語は、ランタイムを共有することにより、より多くの質量を実現します。JVMまたはCLRのいずれかでErlang（ホットコードのロード）とHaskell（より高度な種類のポリモーフィズム）を実行することには技術的な制限があることを理解しています。しかし、ガベージコレクターだけをアンバンドルするのはどうですか？（関数型言語のランタイムの開始を並べ替えます。）割り当ては明らかに高速である必要があるため、そのビットを静的にリンクする必要があります。また、可変ヒープと不変ヒープを区別するためのメカニズムが必要です（ GHCがこれを必要とするため、レイジーライトワンスメモリを含む）。ガベージコレクターがヒープを共有できるように、HIPEとGHCの両方を変更することは可能でしょうか？
経験（ポジティブまたはネガティブ）、アイデア、提案で答えてください。実際、どんなフィードバックでも（まっすぐな虐待を除いて！）大歓迎です。
アップデート
これまでの4つの返信すべてに感謝します。それぞれが、私が知らなかった有用なことを少なくとも1つ教えてくれました。
残りのコーディングライフについては、議論を巻き起こすために頬に少し舌を入れましたが、実際にはそうです。死ぬまで取り組むつもりのプロジェクトがあり、安定したプラットフォームが必要です。
上で提案したプラットフォームでは、ボイラープレートErlangが自動的に生成されるため、Haskellのみを記述します。では、ハスケルはどのくらい続くのでしょうか？さて、Lispはまだ私たちと一緒にいて、すぐになくなるようには見えません。HaskellはBSD3オープンソースであり、クリティカルマスを達成しています。プログラミング自体が50年経ってもまだ存在しているのであれば、Haskell、またはHaskellの継続的な進化がまだここにあると思います。
rvirdingの投稿に応じて2を更新
同意しました-完全な「Erskell/Haslang」ユニバーサル仮想マシンを実装することは絶対に不可能ではないかもしれませんが、それは確かに非常に難しいでしょう。ガベージコレクターレベルをVMのようなものとして共有することは、それでも難しいことですが、私には桁違いに難しいことではありません。ガベージコレクションモデルでは、関数型言語には多くの共通点が必要です。不変データ（サンクを含む）の不公平性と、非常に高速な割り当ての要件です。したがって、共通性がモノリシックVMに緊密にバンドルされているという事実は、ちょっと奇妙に思えます。
VMは、クリティカルマスの達成に役立ちます。F＃やScalaのような「ライト」関数型言語がどのように普及したかを見てください。ScalaはErlangの絶対的なフォールトトレランスを持っていないかもしれませんが、JVMに縛られている非常に多くの人々に逃げ道を提供します。
単一のヒープを使用するとメッセージの通過が非常に速くなりますが、他にも多くの問題が発生します。主に、GCはインタラクティブでグローバルに非中断である必要があるため、実行がより困難になり、per-と同じ単純なアルゴリズムを使用できなくなります。プロセスヒープモデル。
絶対に、それは私には完全に理にかなっています。GHC開発チームの非常に賢い人々は、並列の「世界を止める」GCで問題の一部を解決しようとしているようです。
http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf
（明らかに、「世界を止める」は、その主なユースケースを考えると、一般的なErlangでは飛ばないでしょう。）しかし、「世界を止める」がOKのユースケースでさえ、それらのスピードアップは普遍的ではないようです。だから私はあなたに同意します、普遍的に最高のGCがある可能性は低いです、それは私が私の質問のパート1で指定した理由です
GHCランタイムは、1つのコアのみ、ローカルマシン上のすべてのコア、またはそれらの間の任意の組み合わせを使用するように構成できます。
このようにして、特定のユースケースで、ベンチマークを行った後、Erlangの方法を選択し、1つのGHCランタイム（シングルスレッドGCを使用）とコアごとに1つのErlangプロセスを実行し、Erlangにコア間でメモリをコピーさせてローカリティを高めることができます。 。
または、プロセッサあたり4コアで、プロセッサのメモリ帯域幅が良好なデュアルプロセッサマシンでは、ベンチマークにより、1つのGHCランタイム（並列GCを使用）とプロセッサあたり1つのErlangプロセスを実行することが提案される場合があります。
どちらの場合も、ErlangとGHCがヒープを共有できれば、共有はおそらく単一のコアで実行されている単一のOSスレッドにバインドされます。（私はここで私の深みから抜け出しているので、私は質問をしました。）
また、GCとは独立した関数型言語のベンチマークという別の議題もあります。OCaml v GHC v Erlang v ...のベンチマークの結果をよく読んで、結果がさまざまなGCによってどれほど混乱しているか疑問に思います。GCの選択が関数型言語の選択と直交する可能性がある場合はどうなりますか？とにかくGCはどれくらい高価ですか？この悪魔擁護者のブログ投稿を参照してください
http://john.freml.in/garbage-collection-harmful
私のLispの友人であるJohnFremlinは、魅力的に、彼の投稿タイトルに「自動ガベージコレクションはごみです」と付けています。ジョンがGCが遅く、それほど高速化していないと主張するとき、私はいくつかの数値で対抗できるようにしたいと思います。