Scala 的 actor 与 Go 的协程相似吗？

热负荷

如果我想移植一Goroutines 的 Go 库，Scala 是个不错的选择，因为它的 inbox/akka 框架本质上类似于协程吗？
                                                               
# h& _  G9 O0 b: P" ?: |    解决方案:                                                               
                                                                他们不是。Goroutines 基于 Communicating Sequential Processes 理论，由 Tony Hoare 指定于1978年 。这个想法是，有两个过程或线程是独立的，但共享一个通道，一个过程/线程放置数据进入和另一个过程/线程消耗。你会发现最突出的实现是 Go 通道和 Clojure 的core.async，但此时它们仅限于当前运行，即使在同一物理机器上的两个运行时间之间，也无法分发。
CSP 演变成一个静态和正式的过程代数来证明代码中的死锁。这是一个很好的功能，但 Goroutines 和core.async目前还不支持。如果他们这样做，最好在操作代码之前知道死锁是否可能发生。CSP 不支持有意义的容错，所以作为一名开发人员，你必须找出如何处理通道两侧可能发生的故障，这种逻辑最终会分散在整个应用程序中。
) Z+ U7 U8 J" s演员，正如卡尔休伊特在 1973 年所指定的，涉及拥有自己邮箱的实体。它们本质上是异步的，并且具有跨越运行时和机器的位置透明度——如果您有一个参与者的引用 (Akka) 或 PID (Erlang)，你可以给它发信息。这也是基于 Actor 在实现中发现错误，因为你必须有另一个 Actor 引用可以直接将发送方和接收方发送给它。CSP在模型中，渠道是共享的，可以由多个生产者和消费者共享。根据我的经验，这不是什么大问题。我喜欢代理引用的想法，这意味着我的代码不会充满如何发送信息的细节——我只发送一个，无论演员在哪里，它都会接受。
# T/ S; d# k4 Y+ ]: {Actors 还有一个很好的特点——容错。Erlang 设计在 中OTP 规范将参与者组织到监督层次结构，您可以在应用程序中构建故障域。就像值/DTO/任何你想调用它们的东西，你都可以在层次结构中建模失败、如何处理以及哪个层次。这很强大，因为你在 CSP 内部几乎没有故障处理能力。
Actors 也是并发范式，Actor 除非构建基于 的 ，否则可以在内部有可变状态，并确保没有多线程访问该状态Actor 系统的开发人员不小心介绍了它，比如通过 Actor 注册为侦听器回调，或通过 Futures 在 actor 内部异步处理。
无耻的插件 - 我和 在一起Akka 团队负责人 Roland Kuhn 一起写一本叫 的书Reactive Design Patterns 新书，我们将讨论所有这些和更多的内容。绿色线程，CSP、事件循环、迭代器、反应扩展、Actor、Futures/Promises 等等。预计下个月初前会看到 Manning 的 MEAP。