Erlangの学習とnode.jsの学習
Erlangが考えられるすべてのほぼすべてのカテゴリでnode.jsのお尻を蹴る方法について、オンラインで多くのがらくたを見ています。だから私はアーランを学び、それを試してみたいのですが、ここに問題があります。私は、node.jsを取得するよりも、Erlangを取得することに苦労していることに気づきました。 node.jsを使用すると、比較的複雑なプロジェクトを選択でき、1日で何かが機能しました。 Erlangを使用すると、障壁にぶつかり、ほぼすぐには進みません。
それで、経験豊富な人にとって、Erlangは学ぶのが複雑ですか、それとも私はただ何か不足していますか？ Node.jsは完璧ではないかもしれませんが、私はそれで何かを成し遂げることができるようです。
まず第一に、私はアーランを学ぶことについての私の正しい意見の正解に同意します。これは、ほとんどが関数型言語です（ただし、同時実行性が大きな役割を果たします）。そのすべての機能がフォールトトレランスと堅牢性に向けて追加されましたが、そもそもJavascriptとまったく同じ設計目標ではありません。
2つ目は、Node.jsをそのままにしてErlangに入ることは、少し見当違いです。 Node.jsは単一のサーバー/フレームワークであり、コールバックを利用してイベント駆動型の方法ですべてを実行します。 Erlangには独自のフレームワーク（OTP）がありますが、まったく同じレベルではありません。
Erlangの学習を計画している場合は、私のブログエントリ An Erlang Beginner（or Onlooker）への公開書簡 をチュートリアルに入る前に読んでおくことをお勧めします。
ErlangとNode.jsを比較できる唯一のことは、パターンと使用法に関して、それらがイベント駆動型である方法です。ただし、ここには2つの大きな違いがあります。 Node.jsのモデルは、イベントにバインドされたコールバックに基づいています。 Erlangはメッセージキューと選択的受信に基づいています。そこにはどのような影響がありますか？
まず、コールバックベースの方法で物事を行う場合、状態を持ち運ぶ唯一の方法は、状態をグローバルにするか、継続渡しスタイルのプログラミングに入るかのどちらかです。次に、イベントマトリックス全体を自分で管理する必要があります。この1つの例は、非常に単純な有限状態マシンを想像すると、イベント駆動型のミューテックスセマフォです。
ミューテックスセマフォには、ロックとフリーの2つの状態があります。特定の計算単位（ワーカー、プロセス、関数、またはスレッド）がミューテックスへのアクセスを取得する場合は常に、「興味がある」ことを通知するイベントを起動する必要があります。次のタイプのイベントに注意する必要があります。
- Mutexは無料であり、ロックの取得を要求します
- Mutexが他の誰かによってロックされており、ロックを取得したい
- Mutexは自分でロックしていて、mutexを解放したい
次に、デッドロックを回避するためのタイムアウトなど、考慮すべき追加のイベントがあります。
- ミューテックスがロックされ、あなたがあまりにも長い間待っていた、タイマーが火を放棄する
- ミューテックスがロックされていて、あなたはあまりにも長い間待ち、ロックを取得し、タイムアウトが発生しました
次に、範囲外のイベントもあります。
- ミューテックスをロックしただけで、一部のワーカーはそれが解放されると予測しました。ワーカーのクエリをキューに入れて、解放されたときに処理されるようにします。
- すべての作業を非同期にする必要があります
イベントマトリックスは非常に速く複雑になります。ここのFSMには2つの状態しかありません。 Erlang（または選択的受信および同期イベントの可能性がある非同期の任意の言語）の場合、いくつかのケースに注意する必要があります。
- Mutexは無料であり、ロックの取得を要求します
- Mutexが他の誰かによってロックされており、ロックを取得したい
- Mutexは自分でロックしていて、mutexを解放したい
以上です。タイマーは、受信が行われるのと同じケースで処理され、「解放されるまで待機する」に関係するすべての場合、メッセージは自動的にキューに入れられます。ワーカーは応答を待つだけで済みます。これらの場合、モデルははるかに単純になります。
つまり、一般的なケースでは、CPSおよびnode.jsのようなコールバックベースのモデルは、イベントの処理方法に非常に優れているか、または複雑なイベントマトリックス全体を完全に処理するように要求します。奇妙なタイミングの問題や状態の変化に起因する重要ではないケースごとにコールバックする必要があります。
通常、選択受信では、すべての潜在的なイベントのサブグループにのみ焦点を当てることができ、その場合のイベントについてはるかに簡単に推論することができます。 Erlangはgen_eventと呼ばれるものの振る舞い（デザインパターン/フレームワーク実装）を持っていることに注意してください。 gen_eventの実装により、node.jsで使用されているメカニズムと非常によく似たメカニズムを実現できます。
それらを区別する他のポイントがあります。 Erlangはプリエンプティブスケジューリングを備えていますが、node.jsは協調的ですが、Erlangは一部の非常に大規模なアプリケーション（ディストリビューションなど）に適していますが、Node.jsとそのコミュニティは通常、最新のWebトレンドについてより多くのWebに対応し、精通しています。それは最良のツールを選択することの問題であり、これはあなたの背景、問題のタイプ、および好みに依存します。私の場合、Erlangのモデルは私の考え方にぴったり合っています。これは必ずしもすべての人に当てはまるわけではありません。
お役に立てれば。
Erlangの学習は複雑ではありません。プログラマーのChambers Constant（99.44％）がプログラミングのしくみとして学んでいるという考え方にはまったく異質です。あなたが直面している問題は、実際の複雑さではなく、単に概念的な見当識障害です。
以下は、典型的なプログラマーを噛むことになるErlangの異質な機能の一部です。
- Erlangは（ほとんど）関数型のプログラミング言語です。ほとんどの一般的なプログラミング言語は、ほぼ戦闘的に不可欠です。
- Erlangの並行性モデルはActorモデルです。最も一般的なプログラミング言語では、ロックベースのスレッド化、または並行性に対して何らかの形式の「リアクター」ベースのアプローチを使用しています。 （Node.jsは後者だと思いますが、私を呼び出してはいけません。クライアント/サーバー関係のいずれの側でも、JavaScriptにはまったく興味がありません。）
- Erlangは、これらのクラッシュをキャッチして診断し、システムの実行中にホットパッチするための強力なランタイム機能を使用して、「クラッシュさせます」というコーディング手法を備えています。最も一般的なプログラミング言語は、非常に防御的なプログラミングスタイルを推奨しています。
- Erlangは、信頼できる安定したサーバー（OTP）に一般的に使用されているアーキテクチャーの大規模で穏やかに脳をねじるライブラリーとほぼ完全ですが、完全ではありません。 （Erlangが通常Erlang/OTPと呼ばれるのには理由があります。）さらに、このライブラリは前述のエイリアン機能に基づいて構築されているため、新規参入者にはわかりません。ほとんどのプログラミング言語は、すべてを網羅するライブラリ（Java EEにかかわらず）が少ないため、当然のことながら、ライブラリはほとんどのプログラマにとって馴染みのある概念に基づいて構築されています。
つまり、Erlangを学ぶことは、Node.jsを学ぶことよりも、ほとんどのプログラマにとってより困難なことになるでしょう–特にプログラマがすでにJavaScriptに慣れている場合は。ただし、最後に、概念的な障壁を乗り越えたら、Erlangコーディングは同等のNode.jsコーディングよりもless複雑になると思います。これにはいくつかの理由があります。
- Erlangの並行性モデルは、ロジックの流れを通常の「リアクター」スタイルの並行性よりもはるかに明確にし、並行性を通常のロックベースの並行性よりもはるかに安定かつ正確にします。 Erlangプログラマーが文字通り数千のプロセスを典型的なプログラムでドロップする一方で、たとえばJavaは競合の悪夢（メモリとCPUのオーバーヘッドは言うまでもありません）であり、「リアクター」ベースのセットアップで数千の個別の状態を維持するのと同じことは、読むのが悪夢です。
- Erlangは（ほとんどが関数型の）言語であるため、非常に「見たとおりのものが得られる」セットアップです。変数は、一度設定すると変更されません。ずっと。混乱させるようなOOP "遠くからの不気味なアクション"はありません。操作するものはすべて、目の前に明示的に配置されます。 Xからの継承変数、Yからのクラス変数、Zからのグローバル変数はありません。 （この後者の点は100％正しいわけではありませんが、非常に多くの場合に当てはまるので、学習フェーズには十分です。）
- Erlangがエラーを処理するための強力な機能は、防御的でないプログラミングでコードを整理し、ロジックをより明確に保ち、コードを小さく保つことを意味します。
- OTPライブラリは、ひとたびそれを理解すると、非常に強力な共通コードのスタックであり、アプリケーション全体を定期的に保ち、手遅れになるまで考えられない可能性が高い多くの問題と長期的なサーバーの使用例をカバーします。 OTPライブラリ自体は、IM（ns）HOがErlangを学ぶのに十分な理由です。
できる場合はErlangでログアウトを続けます。まだ行っていない場合は、次のURLにアクセスしてください。Erlangの概念への穏やかで（おもしろい）おもしろい紹介については、 Great YouのErlangを学ぶ にアクセスしてください。
ErlangとNodeの間にはいくつかの重要な違いがあります
1つ目は、そのノードがJavascriptであることです。つまり、より多くの人々が使い慣れている言語と多くの特性を共有する非常に一般的な言語であるため、通常は立ち上げて実行するのがはるかに簡単です。 Erlangは、多くの場合、奇妙でなじみのない構文を持っています。言語はJavaScriptよりもはるかに単純ですが、その独自性のために慣れるのに少し時間がかかります
2つ目は、Erlangには非常に特殊なシェアードナッシング並行処理モデルがあるため、問題を解決するために別の方法で考える必要があることです。これは良いことです（TM）
最後の重要なことは、Erlangが商業会社によって開発され、事実の後にオープンソース化されたことです。それはたった2年前か、ソースコントロールで実際に個々のコミットを実際に見ることができるようになったことです。それらの開発のための公開githubリポジトリに。 node.jsは最初からコミュニティ内に構築されていました。つまり、コミュニティサポートがはるかに優れており、ノード用のライブラリ、コミュニティドキュメント、ライブサンプル、ユビキタスパッケージマネージャーなどがはるかに多くなっています。Erlangが追いついています。この点では、立ち上がるにはまだはるかに大きなランプです。
Nodeを使用すると、楽しいことをかなり速く、比較的簡単にプログラミングできます。erlangが長い間解決してきた大規模なアプリケーションに関しては、依然として問題が増えています。 Erlangはプログラミングの方法を変更し、（imo）はより優れたプログラマーになりますが、最初は簡単ではありません。どちらも違った面で楽しいです。