scala - 为什么在2.10中不推荐使用scala actor？

Question

我只是comparing不同的scala actor实现，现在我想知道是什么原因会导致在2.10版本中弃用现有的scala actor实现并将默认actor替换为Akka实现？ migration guide和first announcement均未给出任何解释。

根据比较，两种解决方案的差异足够大，以至于保留两种方案都是有好处的。因此，我想知道导致该决定的现有实现方案是否存在重大问题？换句话说，这是技术决定还是政治决定？

Answer 1

我不能不给你一个答案:

Akka提供了一个稳定且强大的库来与Actor一起使用，并提供了许多处理高并发性的功能( future ，代理，事务性actor，STM，FSM，非阻塞I / O等)。

而且，它以比scala更为安全的方式实现actor，因为客户端代码只能访问通用ActorRef。这使得除了通过消息传递之外，无法与参与者进行交互。
[编辑:正如Roland指出的那样，这还通过监视层次结构和位置透明性，实现了诸如容错的附加功能:无需在客户端代码上进行任何更改即可在本地或远程部署actor的能力。
整体设计更类似于Erlang中的原始设计。]

在scala和akka角色中，许多核心功能都是重复的，因此，统一似乎是最明智的选择(假设两个库的开发团队现在也属于同一公司:Typesafe)。
主要好处是避免了重复使用相同的核心功能，这只会造成困惑和兼容性问题。

鉴于有选择的余地，仅需决定哪个将是标准实现。

在我看来，Akka在这方面可以提供更多的功能，它是一个成熟的框架，已经包含许多企业级功能，并且在不久的将来还会有更多功能。

我无法想到scala.actors能够完成akka无法完成的特定情况。

ps做出了类似的推理，导致2.10中的标准future/promise实现统一

整个scala语言和社区必须从简化的界面到基本语言功能中受益，而不是由不同框架组成的分散场景，每个框架都有其自己的语法和模型来学习。

对于其他更高级的方面，例如Web框架，则不能说相同的话，开发人员可以从更丰富的可用解决方案中受益。