私はさまざまな scala アクターの実装を比較していましたが、2.10 で既存の scala アクターの実装を非推奨にし、デフォルトのアクターを Akka の実装に置き換える動機は何だったのでしょうか? 移行ガイドも最初の発表も何の説明もしていません。
比較によると、2 つのソリューションは十分に異なっていたので、両方を保持することでメリットが得られました。したがって、この決定の原因となった既存の実装に大きな問題があったかどうか疑問に思っていますか? 言い換えれば、それは技術的な決定でしたか、それとも政治的な決定でしたか?
推測でお答えせざるを得ません。
Akka は、アクターを操作するための安定した強力なライブラリと、高い同時実行性を扱う多くの機能 (フューチャー、エージェント、トランザクション アクター、STM、FSM、ノンブロッキング I/O など) を提供します。
また、クライアント コードは generic にしかアクセスできないという点で、scala よりも安全な方法でアクターを実装しますActorRef。これにより、メッセージ パッシング以外でアクターとやり取りすることができなくなります。
[編集: Roland が指摘したように、これにより、監視階層や場所の透過性によるフォールト トレランスなどの追加機能も有効になります。つまり、クライアント コードを変更することなく、ローカルまたはリモートでアクターを展開することができます。
全体的なデザインは、元の erlang のものにより似ています。]
コア機能の多くは scala アクターと akka アクターで複製されているため、統合が最も賢明な選択のように思われます (両方のライブラリの開発チームも現在同じ会社の一部である: Typesafe)。
主な利点は、同じコア機能の重複を回避することです。これは、混乱と互換性の問題を引き起こすだけです.
どちらを選択するかを考えると、あとは標準実装を決定するだけです。
この点で、Akka には多くのエンタープライズ レベルの機能が既に含まれており、近い将来さらに多くの機能が追加される本格的なフレームワークであることは明らかです。
akka ができないことを scala.actors が達成できる特定のケースは考えられません。
ps 2.10での標準の future/promise実装の統合につながる同様の推論が行われました。
scala 言語とコミュニティ全体は、それぞれが独自の構文と学習モデルを持つ、さまざまなフレームワークで構成された断片化されたシーンではなく、簡素化されたインターフェイスから基本言語機能を取得する必要があります。
開発者が利用可能なソリューションの豊富なパノラマから得られる Web フレームワークなど、他のより高レベルの側面については、同じことは言えません。