Erlangの学習とnode.jsの学習[終了]


41

考えられるほぼすべてのカテゴリーで、Erlangがnode.jsのケツを蹴る方法について、たくさんのがらくたをオンラインで見ます。それで、アーランを学び、試してみたいと思いますが、ここに問題があります。node.jsを拾うよりも、Erlangを拾うのがずっと難しいことに気づきました。node.jsを使用すると、比較的複雑なプロジェクトを選択でき、1日で何かが機能しました。Erlangを使用すると、障壁にぶつかります。

だから..より多くの経験を持つ人にとって、アーランは学ぶのが複雑ですか、それとも何かが足りないのですか?Node.jsは完璧ではないかもしれませんが、私はそれで物事を成し遂げることができるようです。


9
たぶん何かが足りないかもしれませんが、node.jsはJavaScriptライブラリではなく、Erlangは完全に異なる言語ではありませんか?彼らはどのように比較できますか?
FrustratedWithFormsDesigner

3
@ FrustratedWithFormsDesigner、node.jsは、マルチスレッドアプローチでサーバー側でjavascriptを取得する最近の流行/誇大宣伝の一部であるため、同等です
-lurscher

5
@lurscher:Erlang(言語)とNode.js(サーバー側のJavaScript)を比較することはできません。これは、Java(言語)とDjango(サーバーPython)を比較するようなものです。言うまでもなく、ErlangとJSも非常に異なっています。
ジョシュK

10
アーランとノードの両方を使用する人として、彼らは解決する問題で間違いなく匹敵します
デールハーヴェイ

3
@Noliには、node.jsとerlangの間に違いがあります。node.jsとerlangベースのWebサーバーの比較を意味しました。Erlangには、Webサーバー以外にも多くのユーザーがいます。
レイノス

回答:


46

まず第一に、Erlangの学習に関する私の正しい意見の答えに同意します。これはほとんど機能的な言語であり(同時実行が大きな役割を果たします)、その機能のすべてがフォールトトレランスと堅牢性に向けて追加されましたが、そもそもJavascriptとまったく同じ設計目標ではありません。

第二に、Node.jsからErlangに移行することは少し見当違いです。Node.jsは単一のサーバー/フレームワークであり、コールバックの助けを借りてイベント駆動型の方法ですべてを実行します。Erlangには独自のフレームワーク(OTP)がありますが、まったく同じレベルではありません。

Erlangの学習を計画している場合は、チュートリアルに入る前に、ブログエントリ「Erlang初心者(またはOnlooker)の公開レター」を紹介することをお勧めします。


ErlangとNode.jsをパターンと使用法の観点から比較できるのは、それらがイベント駆動型である方法だけです。ただし、ここには2つの大きな違いがあります。Node.jsのモデルは、イベントにバインドされたコールバックに基づいています。Erlangは、メッセージキューと選択的受信に基づいています。そこにはどんな意味がありますか?

まず、コールバックベースの方法で物事を行う場合、状態を保持する唯一の方法は、それをグローバルにするか、継続渡しスタイルのプログラミングに入ることです。第二に、イベントマトリックス全体を自分で管理する必要があります。この一例は、非常に単純な有限状態マシンを想像すると、イベント駆動型のミューテックスセマフォです。

ミューテックスセマフォには、ロックとフリーの2つの状態があります。計算の特定の単位(ワーカー、プロセス、関数、またはスレッド)がミューテックスにアクセスするたびに、「興味がある」ことを通知するイベントを発生させる必要があります。ここで、次のタイプのイベントに注意する必要があります。

  • ミューテックスは無料であり、ロックを取得するように要求します
  • ミューテックスは他の誰かによってロックされており、ロックを取得したい
  • ミューテックスは自分でロックされており、ミューテックスを解放したい

次に、デッドロックを回避するためのタイムアウトなど、考慮すべき追加のイベントがあります。

  • ミューテックスがロックされており、待機時間が長すぎたため、ファイアーを放棄するタイマー
  • ミューテックスがロックされており、待機時間が長すぎてロックを取得し、タイムアウトが発生した

次に、バインドされていないイベントもあります。

  • ミューテックスがフリーであると期待している間にミューテックスをロックしただけです。今、そのワーカーのクエリはキューに入れる必要があります。
  • すべての作業を非同期にする必要があります

イベントマトリックスは非常に高速で複雑になります。ここのFSMには2つの状態しかありません。Erlang(または選択的に受信し、潜在的に同期イベントと非同期する任意の言語)の場合、いくつかのケースに注意する必要があります。

  • ミューテックスは無料であり、ロックを取得するように要求します
  • ミューテックスは他の誰かによってロックされており、ロックを取得したい
  • ミューテックスは自分でロックされており、ミューテックスを解放したい

以上です。タイマーは受信と同じケースで処理され、「空きになるまで待機」に関係するものについては、メッセージは自動的にキューに入れられます。ワーカーは応答を待つだけです。これらの場合、モデルははるかに単純です。

これは、一般的な場合、CPSとnode.jsのようなコールバックベースのモデルは、イベントの処理方法について非常に賢いことを要求するか、複雑なイベントマトリックス全体を完全に処理するように要求することを意味します。奇妙なタイミングの問題や状態の変化に起因する重要でないケースごとにコールバックする必要があります。

通常、選択的受信を使用すると、潜在的なすべてのイベントのサブグループにのみ集中でき、その場合のイベントについてはるかに簡単に推論できます。Erlangには、と呼ばれるものの動作(設計パターン/フレームワーク実装)があることに注意してくださいgen_event。gen_event実装を使用すると、node.jsで使用されているものと非常によく似たメカニズムを使用できます。


それらを区別する他のポイントがあります。Erlangはプリエンプティブスケジューリングを備えていますが、node.jsは協調的であり、Erlangは非常に大規模なアプリケーション(配布およびすべて)により適していますが、Node.jsとそのコミュニティは通常、よりWebに適合し、最新のWebトレンドについて知識があります。最適なツールを選択するかどうかは問題であり、これはあなたの背景、問題の種類、好みに依存します。私の場合、Erlangのモデルは私の考え方にぴったりです。これは、必ずしもすべての人に当てはまるわけではありません。

お役に立てれば。


リアクティブプログラミングの詳細とJSでの実行:blog.flowdock.com/2013/01/22/…–
Bart

「奇妙なタイミングの問題や状態の変化に起因する重要でないケースごとにコールバックする必要があるためです。」-Erlangでは、まだタイマーを処理する必要があり、「受信が行われるのと同じ場合」にそれを行うという事実は、複雑さをまったく変えません。私の観点から(1日あたり数十億のリクエストを処理するシステムのアーキテクトとして)、selective receiveとnode.jsスタイルの唯一の現実的な違いは、(a)「デフォルトで何をしたいのか」という質問です(node.jsで)処理デフォルトではイベントを、そしてErlangのは延期 ...)マッチが起きない限り、イベントを
無バグハーレ

定型の量を含む...と(b)の読みやすさ、(古典Node.jsの中にかなり悪いですが、になったくらい ...そして、どのような場合でも、新たに導入されたのawait演算子と- -と、より良いアーランのものより優れてIMNSHO) 、これらの違いは表面的なものです(両側の熱狂者が説教しているにもかかわらず)。
いいえバグうさぎ

38

Erlangの学習は複雑ではありません。プログラマーのChambers Constant(99.44%)がプログラミングの仕組みとして学んだという考え方には異質です。直面している問題は、実際の複雑さではなく、単なる概念の見当識障害である可能性があります。

以下は、典型的なプログラマーに噛み付くErlangの異質な機能の一部です。

  • Erlangは(ほとんど)機能的なプログラミング言語です。最も一般的なプログラミング言語は、ほとんど戦闘的に必須です。
  • アーランの並行性モデルはアクターモデルです。ほとんどの一般的なプログラミング言語では、ロックベースのスレッド処理または並行性に対する何らかの「リアクター」ベースのアプローチを使用しています。(Node.jsは後者だと思いますが、私に電話しないでください。クライアント/サーバーの関係のいかなる面でもJavaScriptに興味がありません。)
  • Erlangには、システムの実行中にこれらのクラッシュをキャッチし、診断し、ホットパッチするために使用できる強力なランタイム機能を備えたコーディングへの「クラッシュ」アプローチがあります。最も一般的なプログラミング言語は、非常に防御的なプログラミングスタイルを推奨しています。
  • Erlangは、信頼できる安定したサーバー(OTP)のために一般的に使用されるアーキテクチャの大規模で穏やかな脳ねじれライブラリーとほぼ完全にではありませんが、完全に対になっています。(通常、ErlangがErlang / OTPと呼ばれる理由があります。)さらに、このライブラリは、前述のエイリアン機能に基づいて構築されているため、新規参入者には不透明です。ほとんどのプログラミング言語は、動作するライブラリ(Java EEにもかかわらず)が少なく、当然ながら、ほとんどのプログラマーにとって馴染みのある概念に基づいて構築されています。

したがって、Erlangを学ぶことは、特にプログラマーがすでにJavaScriptに精通している場合、Node.jsを学ぶことよりも、ほとんどのプログラマーにとって大きな課題になるでしょう。あなたは概念的な障壁を乗り越えるたら終わりでは、しかし、私はアーランがあることを行っているコーディングすることを提出する以下のコードと同等のNode.jsよりも複雑。これにはいくつかの理由があります。

  • Erlangの並行性モデルは、論理フローを典型的な「リアクター」スタイルの並行性よりもはるかに明確にし、並行性を通常のロックベースの並行性よりもはるかに安定かつ正確にします。Erlangプログラマーが典型的なプログラムで文字通り数千のプロセスをドロップし、Javaが競合の悪夢(関連するメモリとCPUのオーバーヘッドは言うまでもない)にドロップすることは、まったく問題ありません。 「リアクター」ベースのセットアップで数千の個別の状態を維持するのと同じことは、読むのが悪夢です。
  • (ほとんど)機能的な言語であるため、Erlangは非常に「見ているものが得られるもの」セットアップです。変数は、一度設定されると変更されません。今まで。あなたを混乱させるOOPの「離れた場所での不気味なアクション」はありません。作業するものはすべて、あなたの前に明示的に配置されます。Xから継承された変数やYからのクラス変数、Zからのグローバル変数はありません。(後者の点は100%真実ではありませんが、非常に多くのケースで真実であり、学習段階に十分です。)
  • エラーを処理するためのErlangの強力な機能は、より防御的なプログラミングでコードを混乱させることを意味します。したがって、ロジックを明確にし、コードを小さく保ちます。
  • OTPライブラリは、一度見れば、非常に強力な共通コードのスタックであり、アプリケーション全体を定期的に維持し、手遅れになるまで考えられない長生きするサーバーの問題とユースケースの多くをカバーします。OTPライブラリ自体は、IM(ns)HOがErlangを学ぶ十分な理由です。

可能な場合は、Erlangでのコメントを続けてください。まだ行っていない場合は、Earlangの概念についての穏やかで(ほぼ)おもしろい入門をご覧ください


この投稿をありがとう。今、Erlangのいくつかを読んでいて、本の半分を読んでいますが、実際に適度に何かを始める前に、すべてを知る必要があると感じています。重要なのは、だけでなく、作品によってそれに作品を取る
Noliの

1
実際、本の同時実行部分に入ると、適度に重要なことを十分に簡単に行えるようになります。
私の正しい意見

「Erlangの並行性モデルは、論理フローを典型的な「リアクター」スタイルの並行性よりもはるかに明確にします」-リアクターの非同期処理は何十年もの間混乱を招きましたが、未来、特に待機演算子の出現により、もうケース。awaitを使用すると、超軽量コルーチンを「あたかも」スレッドのように動作させることができます(JSについてはわかりませんが、C ++ではco_awaitは数千ではなく数十億にまで拡張できるように設計されていますコルーチン)。
いいえバグうさぎ

「Chambers Constant(99.44%)という考え方にはまったく異質です」-そして、あらゆる産業プロジェクトにとって、これは大きな脂肪問題と見なされます。この大きな脂肪問題は、関数型言語の不人気の客観的な理由がなくても成り立ちます(私は気に留めませんが、これは非常に異なった長い話です)。
いいえバグうさぎ

10

ErlangとNodeにはいくつかの重要な違いがあります

1つ目は、ノードがJavascriptであるということです。これは、より多くの人が使い慣れている言語と多くの特徴を共有する非常に一般的な言語であるため、通常は起動と実行がはるかに簡単です。Erlangには、ほとんどの場合、奇妙で馴染みのない構文があります。言語はjavascriptよりもはるかに単純ですが、その独自性のために少し慣れる必要があります

2つ目は、Erlangには非常に特別な非共有型同時実行モデルがあるため、問題を解決するために別の方法で考える必要があるため、良いことです(TM)

最後の重要なことは、Erlangは営利会社によって開発され、オープンソース化されたという事実です。それはたった2年前であり、ソース管理で個々のコミットを実際に見ることができ、今でもすべてのerlang開発者が動いたとは思いませんgithubリポジトリを開発のために公開します。node.jsは最初からコミュニティ内に構築されました。これは、コミュニティのサポートがはるかに優れていることを意味します。ノード用のライブラリ、コミュニティドキュメント、ライブサンプル、ユビキタスパッケージマネージャなどが既にあります。この点では、まだ立ち上がるためのはるかに大きなランプです。

Nodeを使用すると、楽しいことを非常に迅速かつ比較的簡単にプログラミングできますが、erlangが長い間解決してきた大規模なアプリケーションに関しては、依然として大きな痛みがあります。Erlangはあなたのプログラミング方法を変え、(imo)あなたをより良いプログラマーにしますが、それは最初はあなたにとって人生を楽にしません。両方とも異なる方法で楽しいです。


2
Nodeのスレッドも「何も共有しない」ことに言及する価値があります。
タムリン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.