我只是comparing个不同的scala actor实现，现在我想知道在2.10中弃用现有scala actor实现并用Akka实现替换默认actor的动机是什么？ migration guide和first announcement都没有给出任何解释。
根据比较，两种解决方案的不同之处在于保持两种解决方案都是有益的。因此，我想知道导致这一决定的现有实施是否存在任何重大问题？换句话说，这是一个技术或政治决定吗？
答案 0 :(得分：21)
我不得不给你一个猜测答案：
Akka提供了一个稳定而强大的库来与Actors一起工作，以及许多处理高并发性的功能（期货，代理，事务参与者，STM，FSM，非阻塞I / O，......）。 / p>
它还以比scala更安全的方式实现actor，因为客户端代码只能访问泛型ActorRef。这使得除了通过消息传递之外不可能与演员互动
[编辑：正如Roland所指出的，这还可以通过监督层次结构和位置透明度启用容错等附加功能：部署能力本地或远程的演员，客户代码无需更改
整体设计更像是erlang中的原始设计。]
scala和akka演员中的大部分核心功能都是重复的，所以统一似乎是最明智的选择（假设两个图书馆的开发团队现在也是同一家公司的一部分：Typesafe）。
主要收获是避免重复相同的核心功能，这只会产生混淆和兼容性问题。
鉴于选择到期，只能决定哪个是标准实施。
对我来说很明显，Akka在这方面可以提供更多功能，是一个包含许多企业级功能的完整框架，并且在不久的将来会有更多功能。
我想不出scala.actors能够完成akka无法实现的特定情况。
P.S。类似的推理导致了2.10
中标准future/promise实现的统一整个scala语言和社区必须从基本语言功能的简化界面中获益，而不是由不同框架组成的碎片化场景，每个框架都有自己的语法和模型来学习。
对于其他更高层次的方面，例如网络框架，开发人员可以从更丰富的可用解决方案中获益，这是不可能的。