Node.jsに対するHaskellの応答とは何ですか？

Erlangコミュニティは、非ブロッキングI / Oをネイティブで実行し、デプロイメントを複数のプロセッサー（Node.jsに組み込まれていないもの）まで簡単に拡張できる方法があるため、Node.jsにうらやましくないと思います。詳細については、http：//journal.dedasys.com/2010/04/29/erlang-vs-node-jsおよびNode.jsまたはErlangをご覧ください。

ハスケルはどうですか？HaskellはNode.jsのいくつかの利点、つまりマルチスレッドプログラミングに頼ることなくI / Oのブロックを回避するクリーンなソリューションを提供できますか？

Node.jsには魅力的なものがたくさんあります

1. イベント：スレッド操作はありません。プログラマーはコールバックのみを提供します（Snapフレームワークの場合と同様）。
2. コールバックは単一のスレッドで実行されることが保証されており、競合状態は発生しません。
3. 素晴らしくシンプルなUNIXフレンドリーなAPI。ボーナス：優れたHTTPサポート。DNSも利用できます。
4. すべてのI / Oはデフォルトで非同期です。これにより、ロックを回避しやすくなります。ただし、コールバックでのCPU処理が多すぎると、他の接続に影響します（この場合、タスクはより小さなサブタスクに分割され、再スケジュールされます）。
5. クライアント側とサーバー側で同じ言語。（ただし、この例ではあまり価値を見ていません。jQueryとNode.jsはイベントプログラミングモデルを共有していますが、残りは大きく異なります。サーバー側とクライアント側の間でコードを共有する方法がわかりません。実際に役立つ。）
6. これらすべてが1つの製品にパッケージ化されています。

OK、@ gawiが指摘したnode.jsのプレゼンテーションを少し見てきたので、Haskellとnode.jsの比較についてもう少し説明できます。プレゼンテーションでは、ライアンはグリーンスレッドのいくつかの利点について説明しますが、スレッドの抽象化がないことは不利であるとは言いません。特にHaskellのコンテキストでは、彼の立場に同意しません。スレッドが提供する抽象化は、サーバーコードをより簡単に、より堅牢にするために不可欠であると思います。特に：

• 接続ごとに1つのスレッドを使用すると、すべてのクライアントを同時に処理するコードを記述するのではなく、単一のクライアントとの通信を表すコードを記述できます。このように考えてみてください。複数のクライアントをスレッドで処理するサーバーは、単一のクライアントを処理するサーバーとほとんど同じように見えます。主な違いはfork、前者のどこかにあることです。実装しているプロトコルがまったく複雑な場合、複数のクライアントの状態マシンを同時に管理するのは非常に難しくなりますが、スレッドでは単一のクライアントとの通信をスクリプト化するだけで済みます。コードは、正しく理解しやすく、理解と保守が容易です。

• 単一のOSスレッドでのコールバックは、スレッドで得られるプリエンプティブマルチタスクとは対照的に、協調的なマルチタスクです。協調型マルチタスクの主な欠点は、飢餓がないことを確認する責任がプログラマーにあることです。モジュール性が失われます。1つの場所でミスをすると、システム全体が台無しになります。これは本当に心配したくないものであり、プリエンプションは簡単な解決策です。さらに、コールバック間の通信は不可能です（デッドロックになります）。

• Haskellでは並行性は難しくありません。なぜなら、ほとんどのコードは純粋であり、構造上スレッドセーフだからです。シンプルな通信プリミティブがあります。制限のない副作用のある言語よりも、Haskellで同時実行して自分自身を撃つのははるかに困難です。

HaskellはNode.jsのいくつかの利点、つまりマルチスレッドプログラミングに頼ることなくI / Oのブロックを回避するクリーンなソリューションを提供できますか？

はい、実際、イベントとスレッドはHaskellで統合されています。

• 明示的な軽量スレッドでプログラミングできます（たとえば、1つのラップトップで数百万のスレッド）。
• または; スケーラブルなイベント通知に基づいて、非同期のイベント駆動型でプログラミングできます。

スレッドは実際にはイベントの観点から実装され、複数のコアにまたがって実行され、シームレスなスレッド移行、ドキュメント化されたパフォーマンス、およびアプリケーションを備えています。

たとえば

• 大規模な並行ジョブオーケストレーション
• 32または48コアでの同時収集スケーリング
• マルチスレッド/マルチイベントプログラムのプロファイリングとデバッグのためのツールサポート。
• 高性能のイベント駆動型Webサーバー。
• 興味深いユーザー：高頻度取引など。

32コアの同時収集nbody

Haskellでは、イベントとスレッドの両方があり、すべてのイベントが内部にあります。

実装について説明した論文を読んでください。

最初に、node.jsがこれらすべてのコールバックを公開して正しいことをしているという見方を私は保持していません。あなたは最終的にCPS（継続渡しスタイル）でプログラムを書くことになり、その変換を行うのはコンパイラーの仕事であると私は思います。

イベント：スレッド操作はありません。プログラマーはコールバックのみを提供します（Snapフレームワークの場合と同様）。

したがって、これを念頭に置いて、必要に応じて非同期スタイルを使用して書き込むことができますが、そうすることにより、リクエストごとに1つのスレッドを使用して、効率的な同期スタイルで書き込むことができなくなります。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。

これらすべてが1つの製品にパッケージ化されています。

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以上のコアに効率的にスケーリングし、1台のマシンで毎秒2,000万を超える新しいリクエストのスループットに到達できるため、既存のすべてのSDNコントローラーの中で最速になることも示しています。

MioはそれをGHC 7.8.1リリースにしました。私はこれをHaskellのパフォーマンスにおける大きな前進だと個人的に見ています。以前のGHCバージョンと7.8.1でコンパイルされた既存のWebアプリケーションのパフォーマンスを比較することは非常に興味深いでしょう。

IMHOイベントは良いですが、コールバックによるプログラミングは良くありません。

Webアプリケーションのコーディングとデバッグを特別にする問題のほとんどは、Webアプリケーションをスケーラブルで柔軟性のあるものにすることに起因しています。最も重要なのは、HTTPのステートレスな性質です。これにより、操作性が向上しますが、これにより、IO要素（この場合はWebサーバー）がアプリケーションコード内の異なるハンドラーを呼び出す制御が逆になります。コールバックは変数のスコープを共有せず、ナビゲーションの直感的なビューが失われるため、このイベントモデル（より正確には、コールバックモデル）は悪夢です。ユーザーが前後にナビゲートするときに、考えられるすべての状態変化を防ぐことは非常に困難です。

問題は、イベントモデルが正常に機能するGUIプログラミングに似ていますが、GUIにはナビゲーションと戻るボタンがありません。これにより、Webアプリケーションで可能な状態遷移が増加します。これらの問題を解決する試みの結果は、複雑な構成の重いフレームワークであり、問​​題の根本に疑問を投げかけることなく、広範なマジック識別子がたくさんあります。識別子をリンクすることによって構築されます。

ocsigen（ocaml）seaside（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万（シンプル）リクエストを実行できます。ノードは多くのことを行うことはできず、単一のアプリケーションをコア全体に拡張することはできません。そして、Haskellランタイムはノンブロッキングなので、これを取得するために何もする必要はありません。ランタイムに非ブロッキングIOが組み込まれている他の（比較的一般的な）言語は、Erlangだけです。

同じようにnodejsがlibevは低下しているスナップハスケルのWebフレームワークは、libevは低下している、あまりにも。