akkaとErlangの違いは?[閉まっている]


97

私は最近アッカを見ていて、それはかなり印象的です。場所の透過性、監視階層など、erlangのキラー機能のほとんどを持っているようです。erlangにakkaにはない機能はありますか?


アーランに関する実際の映画をご覧ください。scalaについては何もありませんyoutube.com/watch?v=G0eBDWigORY
mhstnsc

回答:


123

免責事項:私はAkkaのPOです

  • Erlangはコピーオン送信を行います-AkkaはVM内送信に共有メモリ(不変オブジェクト)を使用します
  • ErlangはプロセスごとのGCを行います-AkkaはJVM GCを使用します
  • ErlangにはOTPがあります-AkkaはJavaエコシステム全体(Apache Camel、JAX-RSなど)と統合します
  • Erlangがプロセスのスケジューリングを行います-Akkaでは、さまざまなディスパッチャを使用して、構成の機会を無限に広げることができます
  • Erlangはホットコードのリロードを行います-Akkaはそれをサポートできますが、JVMクラスローディングのために柔軟性が低くなります

それらは私の頭の上からのものです。

一方、Akkaを使用すると、Scala、Java、Groovy、またはJRubyを使用してアプリケーションを作成できるようになります。


39
Erlangオブジェクトも不変であり、並行性モデルは同じノード内での送信時コピーを必要としません。ラージオブジェクトのBEAM は参照を送信します。出典:この@rvirdigにより、SOの答え
FooF

26
ErlangはGCをより効率的にするためにコピーオンセンドを行います-それはプロセスごとに動作できます。これが、JVM / Akkaアプリとは対照的に、Erlangアプリに大きなGCの一時停止がない理由です。
andreypopp

4
まあ、アンドレイ、その種類は、使用しているJVM / GCに依存します。azulsystems.com/products/zing/whatisit
Viktor Klang

4
Erlangは各プロセスの削減数を持っています。忙しい重い計算ループにいる場合でも、Erlang VMはプロセスを一時停止し、他の空腹なプロセスがより多くのCPUサイクルをとることができます。これは、JVMが提供しない非常に重要な機能です。
Daniel

6
@MaX Erlangは、JITサポートがないため、Javaよりも5倍遅くなることがよくあります。ただし、ErlangにはGCの一時停止機能がなく、同時実行および7 * 24テレコムアプリケーション向けに設計されています。Erlangはプロセスの公平性を重視し、飢餓とデッドロックを回避します。JVMのようなスループット用には設計されていません。だから、それは本当にオレンジとリンゴです。
Daniel

74

Erlangでは、プロセスは約1000削減ごとに切り替えられることが保証されています。Scala / Akkaエージェントのような単純なフレームワークでは、受信での作業が完了するまでスケジューラを所有します。チェックメイト。ゲームオーバー。ハスタ・ラ・ビスタ:)人々、疑似技術に時間を浪費しないでください。ここの人たちはScalaをErlangと比較しているのに驚いた。

また、他にも多くのいわゆる「キラー機能」がありますが、これは私のアドバイスです。機能の観点からは考えず、特定の言語を可能にするイディオムについて考えてください。Scalaは「最良の機能」を盗み、Erlangは正しいイディオムを使用可能/実装して、これらの正しいイディオムから駆動される高水準言語でシステムを確実に構築します。Erlangを学ぶとき、あなたは心を再構築し、分散された信頼性の高いシステムについてのあなたの考え方を学び、Erlangはあなたに教え、あなたをアップグレードします。Scalaは、他の言語から優れた機能を盗もうとするもう1つの必須の言語です(ああ、申し訳ありませんが、多パラダイムで面白い単語です)。


9
すべてのIOを暗黙的に非同期にするErlangの方法は非常にエレガントです。非同期IOは、ScalaのNIO APIを使用して実行できます。これは、私にはチェックメイトのようには見えませんが、洗練されていないソリューションです。
HRJ 2011

7
一体何を話しているの!?ラウンドロビンスケジューリングよりも、または最小のメールボックススケジューリングに近い場合でも、1000のストレートタスクをどのように処理するのが優れていますか。
FUD 2013年

8
@vjache-同意します。Javaプログラマーとしての私の長年の経験から、ある時点で自分の下のレイヤーを調査する必要があることを学びました。Scala / Akkaは、他の多くのレイヤー(たとえば、nio、nettyなど)の上にある別のレイヤーのように見えます。これらはすべて、ある時点で理解する必要があります。私はErlangでの作業を開始したばかりですが、仕事を完了するために理解する必要があるレイヤーが少なくなるようです。Erlangでの分散プログラミングはScala / Akkaの方がはるかに軽量であると感じています。おそらく、PythonがWebアプリのJavaに代わる軽量な代替手段であったのと同じように。
Chris Snow

@FUD:多分彼は1000のErlang命令を意味しましたか?彼は1000通のメッセージを意味することはできなかった...
エリックカプルーン

2
@ErikAllik彼は1000の「削減」を意味しました。リダクションは、少しのコードを実行するためのトークンと考えてください(そうではありませんが、説明するのに役立ちます...)。1000回の削減後、スケジューラは別のプロセスに切り替えます。詳細については、erlang.org / pipermail / erlang
Aegis

40

プロセスの分離についてはほとんど誰も言及していません。「あなたのスレッドが私のがらくたを混乱させることはできない」という保証がないと、分散システムは推論するのがはるかに困難になります。(それらはErlangのプロセスはすでに十分に困難です。)

AFAIK(これは、JVMでの直接の経験が限られていることを考えると、それほど遠くない)であり、JVMで実際にプロセスを分離できるのはErlangだけです。グーグル氏は、「マイクロ再起動」技術(「リカバリー指向コンピューティング」)を使用する研究システムに関するFoxおよびCandea(?)の研究をどこで見つけるかについてのヒントを与えることができます。Erlangの開発者はその研究を読み、いくつかのことを言います:

  1. クラブへようこそ、何がそんなに長くかかりましたか?
  2. ただし、JVMを使用すると、参加が非常に困難になります。:-)

プロセスの分離は本当に素晴らしいです。ただし、Erlangでさえ、失敗したNIFの影響を受けません。
Viktor Klang

14

私にとって、ダウンタイムなしのErlangクラスタ全体でのホットコードスワップ(例make:all([netload]:)は、Erlangキラー機能の1つです。

しかし、あなたの質問を逆転させましょう:alangにはErlangにはない何がありますか?もちろん、Javaに何十もの拡張機能とライブラリ(scala、akka、spring、osgiなど)を追加して、Erlangに近づけることができます。しかし、ポイントはどこですか?つまり、これらすべての拡張機能は、20年以上にわたってダウンタイムなしで最高のスケーラビリティを提供できることが証明されている単純なErlang言語を学ぶよりもはるかに複雑です。


30
IMO、ScalaはErlangよりも構文レベルではるかに優れた言語です。オブジェクト、特性、適切な名前空間、適切なタイプセーフ、醜いレコード構文などはありません。コミュニティは大きく、利用可能なすべてのJavaツールを使用でき、洗練されているように感じます。
ryeguy

15
@ryeguy:「構文レベルのより良い言語」...うーん、「構文」の「より良い」を定義します。私が言語を比較するとき、構文は最も無関係な要素です(なぜならそれは好みの問題か、またはあなたが慣れているものの問題だからです)。
Peer Stritzinger、2010

4
@ryeguy異なるセマンティクス、異なる構文。
2010

3
異なるコードバージョン間で状態を維持する必要がある場合、ホットコードスワッピングは
面倒に

4
@ryeguyプログラミング言語の構文は重要ではありません。重要なのはそのセマンティクスです。Erlangは機能的なPLなので、もちろんオブジェクトはありません。特性、型安全性などは、Scalaが強く型付けされた言語であるのに対し、Erlangは動的に型付けされます。それは設計上の選択です。それでも、Erlangの利点をよりモダンな感覚で知りたい場合は、Elixirをご覧になることをお勧めします;)
Aegis

5

おそらく、Erlangは(vjacheの答えに従って)より大きな分散システムに適していますが、通常のサーバーでは、複数のCPUの能力を最大限に活用したい場合は、Akkaが適切な選択です。抽象化、パフォーマンス、およびJavaエコシステムとの統合を提供します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.