Java Groovy和Grails vs Scala，为什么Twitter选择Scala？

我有一个非常基本的问题：为什么Twitter选择Scala而不是Groovy来从Ruby切换？我认为使用Groovy对Rubyist或Javaman来说比Scala更容易。谢谢。

也许你可以在这里找到答案：

“可靠的高性能代码”一段很好地抓住了这一点：-）

比尔·维纳斯（Bill Venners）：我很好奇，Ruby的人会希望拼写出来 你能详细说明一下你觉得Ruby语言缺少什么吗 可靠、高性能代码的领域

史蒂夫·简森：我在职业生涯中发现的一件事是 需要具有长寿命的流程。还有Ruby，就像许多脚本一样 语言，很难成为长寿命进程的环境。 但是JVM在这方面非常出色，因为它已经为此进行了优化 在过去的十年里。所以Scala提供了写作的基础 长寿命的服务器，而这正是我们在Twitter上使用它的主要目的 马上我们真正喜欢Scala的另一件事是静态类型 这并不痛苦。有时候，在Ruby中说 比如，这里有一个可选的类型注释。这就是我们要的类型 我真的很期待看到这里。我们发现这在Scala中非常有用 能够指定类型信息

robeypointer：此外，Ruby还没有很好的线程支持。 它正在变得更好，但当我们编写这些服务器时，green 线程是唯一可用的东西。绿色线程不使用 实际操作系统的内核线程。它们有点像线程 通过定期停止他们正在做的事情并检查 另一个“线程”要运行。所以Ruby在一个 单核或处理器。我们希望在多核服务器上运行 没有无限的记忆。如果你没有 良好的线程支持，您确实需要多个进程。及 因为Ruby的垃圾收集器不如Java的好，所以每个 这个进程占用了大量内存。我们真的不能运行很多Ruby 守护进程在一台机器上运行，而不消耗大量资源 记忆。而通过在JVM上运行东西，我们可以运行很多 线程在同一堆中，并让该进程占用所有 机器的运动场内存

亚历克斯·佩恩（Alex Payne）：我一定要把史蒂夫的话讲清楚 打字。随着我们系统的发展，我们的Ruby系统中有很多逻辑 某种程度上复制了一个类型系统，无论是在我们的单元测试中还是作为 模型验证。我认为这可能只是一个大的财产 动态语言中的系统，最终您将重写 你自己的类型系统，你做得很差。你在检查 到处都是空值。有很多人打电话给Ruby's 什么样的？方法，它会问，“这是一种用户对象吗？因为 这正是我们所期待的。如果我们没有得到，这将是 当有一个故事发生时，不得不写下所有这些，真是太遗憾了 在编程语言世界中已经存在了多年的解决方案 几十年了

---

事后看来，他们可能认为这是一个理性的决定，但我们知道。。。斯卡拉只是一个很酷的新玩具

没有任何合理的理由选择新的、未经验证的、未经测试的生产系统来实现

---

开发商以不考虑风险而闻名。这些人很幸运。我们没有听说有人不是这样的。

虽然只有Twitter可以回答这个问题，但你基本上问错了问题。你应该问问自己，是什么业务或技术问题使Scala对Twitter有用

事实上，如果你阅读，你会发现他们不仅仅是扔掉了铁轨；他们构建系统以支持Scala中的部分应用程序，并重构现有代码以与Scala中构建的服务对话

在某种程度上，他们主要的技术关注点不再是web应用本身，而是更多地关注消息和通知。Groovy和Grails不会比Rails更好（或者更好）地帮助他们解决这个问题。Scala和其他函数式语言通过最小化可变状态，使得对高度并发问题进行推理变得更加容易。它为并发问题提供了一个参与者模型，使得将某些类别的应用程序扩展到多个处理器和多个服务器变得更加容易

这就是为什么您的曲目中应该有多个工具的基本原因。有些问题并不像存储和显示数据那么简单。使用纯Ruby工具可以走得很远，但在处理需要线程或跨多台机器分发的问题时，仍然存在一些实际限制

---

考虑到不同的团队成员或动机，他们可能很容易选择Erlang甚至F#。但是，如果另一个web框架的问题不是真正出现在前端，那么它可能会以更大的成本提供很少的好处。

是的，是的。。。否决票：-）就像它会改变事实：Ruby跟不上，Scala很酷，Java很无聊。不管他们现在怎么说，这个选择是不合理的。他们采用Scala的时候它已经有好几年的历史了，而且它肯定不仅仅是一个新玩具。有时大肆宣传是有原因的。（顺便说一句：我不是反对者，每个人都应该有权有自己的误解……呃……观点）作为一名专业的Scala开发人员，我仍然觉得你的评论很有趣：-）我相信早期采用者日子不好过。至于现在（2011年），我不再认为自己是一个早期采用者。这应该是一个怎样的答案？至少它没有用。这种性质的主张需要更多的证据来支持。他们确实在文章中提到了“酷新玩具”这一方面，但这似乎也有助于解决他们的性能问题