这里有两个问题：
这是一个简单的问题，因为Scala是一种通用语言，它不比可以选择“移植goroutines”的其他语言更好或更糟。
当然，对于为什么Scala作为一种语言更好还是更坏，有很多观点（例如，这是我的观点），但这只是观点，不要让它们阻止您。由于Scala是通用的，因此“差不多”可以归结为：您可以使用X语言进行的所有操作，都可以使用Scala进行。如果听起来太宽泛.. Java的延续如何:)
唯一的相似之处（除了挑剔之外）是它们都与并发和消息传递有关。但这就是相似性结束的地方。
由于Jamie的答案很好地概述了Scala演员，因此，我将重点介绍Goroutines / core.async，但会介绍一些演员模型。
演员帮助事情“无忧无虑地分发”
其中“无忧”片通常与诸如有关：fault tolerance，resiliency，availability等。
在不涉及参与者如何工作的严肃细节的情况下，参与者必须用两个简单的术语进行说明：
- 位置：每个参与者都有一个地址/引用，其他参与者可以使用该地址/引用向其发送消息
- 行为：当消息到达参与者时被应用/调用的函数
想想“对话过程”，其中每个过程都有一个引用和一个消息到达时调用的功能。
当然还有更多的功能（例如查看Erlang OTP或akka docs），但是以上两个是一个好的开始。
与演员一起有趣的地方是..实现。目前，有两个大公司是Erlang OTP和Scala AKKA。他们俩都致力于解决同一件事，但存在一些差异。让我们来看几个：
我故意不使用诸如“参照透明性”，“幂等性”之类的术语。它们除了造成混乱之外没有其他好处，所以我们只讨论不变性[一个can't change that概念]。人们普遍认为Erlang是一种语言，它倾向于强大的不变性，而在Scala中，让参与者在收到消息时更改/更改其状态太容易了。不建议这样做，但是Scala中的可变性就在您的面前，并且人们确实在使用它。
Joe Armstrong谈到的另一个有趣的观点是，Scala / AKKA受JVM的限制，而JVM并不是真正被设计为“分散”的，而Erlang VM却是。它与许多事情有关，例如：进程隔离，每个进程与整个VM垃圾收集，类加载，进程调度等。
上面的意思并不是说一个优于另一个，而是要表明参与者模型作为一个概念的纯度取决于它的实现。
现在到goroutines。
Goroutine有助于顺序推理并发
正如其他答案已经提到的那样，goroutines起源于Communicating Sequential Processes，这是一种“用于描述并发系统中交互模式的形式语言”，根据定义，这可能意味着很多:)
我将基于core.async给出示例，因为我比Goroutines更了解它的内部。但是core.async是在Goroutines / CSP模型之后构建的，因此从概念上讲应该不会有太多差异。
core.async / Goroutine中的主要并发原语是一个channel。可以将achannel视为“岩石上的队列”。该通道用于“传递”消息。任何想“参与游戏”的过程都会创建或获取对a的引用，并向其channel发送/接收（例如发送/接收）消息。
免费24小时停车
在通道上完成的大部分工作通常都在“ Goroutine ”或“ go block ”内部进行，“ Goroutine ”或“ go block ”会拿住它的主体并检查它是否进行了任何通道操作。它将主体变成一个状态机。状态机将被“停放”，并释放实际的控制线程。这种方法类似于C＃异步中使用的方法。当阻塞操作完成时，代码将恢复（在线程池线程上，或者在JS VM中的唯一线程） ”（源）。
用视觉传达要容易得多。阻塞的IO执行如下所示：
您可以看到线程主要花费时间在等待工作上。这是相同的工作，但通过“ Goroutine” /“ go block”方法完成：
这里有2个线程完成了所有工作，而4个线程以阻塞方式完成了所有工作，同时花费了相同的时间。
上面描述中的关键是：没有工作时“线程被停放”，这意味着它们的状态被“卸载”到状态机，并且实际的实时JVM线程可以自由地做其他工作（源于出色的视觉效果）
注意：在core.async中，可以在“ go block”之外使用通道，通道将由JVM线程支持，而没有停放能力：例如，如果它阻塞，它将阻塞实际线程。
转到频道的力量
“ Goroutines” /“ go blocks”中的另一个重要之处是可以在通道上执行的操作。例如，可以创建一个超时通道，该通道将在X毫秒内关闭。或选择/替代！当与许多渠道结合使用时，该功能就像跨不同渠道的“您准备好了”轮询机制一样。可以将其视为非阻塞IO中的套接字选择器。这是一起使用timeout channel和的示例alt!：
(defn race [q]
(searching [:.yahoo :.google :.bing])
(let [t (timeout timeout-ms)
start (now)]
(go
(alt!
(GET (str "/yahoo?q=" q)) ([v] (winner :.yahoo v (took start)))
(GET (str "/bing?q=" q)) ([v] (winner :.bing v (took start)))
(GET (str "/google?q=" q)) ([v] (winner :.google v (took start)))
t ([v] (show-timeout timeout-ms))))))
此代码段来自wracer，在其中将相同的请求发送到所有三个：Yahoo，Bing和Google，并从最快的一个返回结果，或者如果在给定时间内没有返回结果则超时（返回超时消息）。Clojure的可能不是你的第一语言，但你可以不同意就如何顺序此实现并发的外观和感觉的。
您还可以合并/散入/散出来自/到许多通道的数据，映射/减少/过滤/ ...通道数据等等。频道也是头等公民：您可以将频道传递给频道。
去UI去！
由于core.async“执行块”具有“执行”状态的“能力”，并且在处理并发时具有非常连续的“外观”，因此JavaScript呢？JavaScript中没有并发，因为只有一个线程，对吗？并发的模仿方式是通过1024个回调。
但这不必是这种方式。上面来自wracer的示例实际上是用ClojureScript编写的，可编译为JavaScript。是的，它将在具有多个线程的服务器上和/或在浏览器中运行：代码可以保持不变。
Goroutines vs.core.async
再次，在实现上存在一些差异[还有更多]强调了以下事实：理论概念在实践中并不完全一对一：
- 在Go中，输入的是通道，而在core.async中则不是：例如，在core.async中，您可以将任何类型的消息放在同一通道中。
- 在Go中，您可以将可变的内容放在频道上。不建议这样做，但是可以。通过Clojure设计，在core.async中，所有数据结构都是不可变的，因此通道内的数据对其安全性而言要安全得多。
那么判决是什么？
我希望以上内容可以阐明参与者模型和CSP之间的差异。
并不是要引起大战，而是要给您另一个视角，例如Rich Hickey：
“我对参与者仍然不热心。他们仍然将生产者与消费者结合在一起。是的，一个人可以与参与者模仿或实现某些队列（尤其是人们经常这样做），但是由于任何参与者机制已经包含了队列，因此队列似乎更原始了。应该注意的是，Clojure的状态并发使用机制仍然可行，并且通道面向系统的流量方面。 ”（（源）
但是，实际上，Whatsapp是基于Erlang OTP的，并且似乎卖得很好。
另一个有趣的报价来自Rob Pike：
“缓冲将不予确认发件人和可以任意长拿。缓冲通道，够程是非常接近的角色模型。
演员模型和Go的真正区别在于渠道是一等公民。同样重要的是：它们是间接的，就像文件描述符而不是文件名一样，允许并发样式在actor模型中不那么容易表达。在某些情况下，情况相反。我没有做出价值判断。理论上，模型是等效的。“（来源）