Groovy and Grails vs Scala，为什么Twitter选择Scala？[已关闭]

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

事实上，如果你读到Twitter在Scala中集成代码，你会发现他们不只是抛弃了Rails;他们构建了系统来支持Scala中应用程序的一部分，并重构了现有代码，以便与Scala中构建的服务进行通信。

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

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

他们可能很容易地选择了Erlang甚至F#，因为有一组不同的团队成员或动机。但是，另一个Web框架可能会以更可观的成本提供很少的好处，而他们的问题并不真正在前端。

也许你可以在这里找到你的答案：http://www.artima.com/scalazine/articles/twitter_on_scala.html

段落“可靠，高性能代码”很好地抓住了它：-）。

Bill Venners：我很好奇，Ruby的人会希望它拼写出来：你能详细说说你觉得Ruby语言在可靠的高性能代码领域缺乏什么吗？

Steve Jenson：在我的整个职业生涯中，我发现的一件事是需要有长期的流程。而 Ruby 和许多脚本语言一样，在成为长寿命进程的环境方面遇到了麻烦。但是JVM在这方面非常擅长，因为它在过去十年中已经为此进行了优化。因此，Scala为编写长寿命服务器提供了基础，而这正是我们现在在Twitter上使用它的主要目的。我们真正喜欢Scala的另一件事是静态类型，它并不痛苦。有时在 Ruby 中说这样的话会很好，这里有一个可选的类型注释。这是我们真正期望在这里看到的类型。我们发现这在Scala中非常有用，能够指定类型信息。

Robey Pointer：另外，Ruby还没有很好的线程支持。它正在变得越来越好，但是当我们编写这些服务器时，绿色线程是唯一可用的东西。绿色线程不使用实际操作系统的内核线程。它们通过定期停止它们正在执行的操作并检查另一个“线程”是否要运行来模拟线程。因此，Ruby正在模拟单个内核或处理器内的线程。我们希望在没有无限内存量的多核服务器上运行。如果你没有良好的线程支持，你真的需要多个进程。而且由于Ruby的垃圾回收器不如Java的好，所以每个进程都会消耗大量内存。我们无法在不消耗大量内存的情况下在一台机器上运行很多Ruby守护进程。而在JVM上运行东西，我们可以在同一堆中运行许多线程，并让该进程将所有机器的内存用于其游乐场。

亚历克斯·佩恩：我肯定想把史蒂夫关于打字的话带回家。随着我们系统的发展，Ruby系统中的许多逻辑都复制了一个类型系统，无论是在我们的单元测试中，还是作为模型上的验证。我认为这可能只是动态语言中大型系统的一个属性，最终你最终会重写你自己的类型系统，而且你做得有点糟糕。您正在检查所有地方的空值。有很多调用 Ruby kind_of？方法，它问，“这是一种用户对象吗？因为这就是我们所期待的。如果我们不明白这一点，这将爆炸。当编程语言世界中已经存在了几十年的解决方案时，不得不编写所有这些内容真是太可惜了。