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

Groovy and Grails vs Scala, Why Twitter choose Scala?

提问by setyo

I have a very basic question: Why did Twitter choose Scala rather than Groovy to switch from Ruby? I think using Groovy is easier for the Rubyist or Javaman than Scala. Thanks.

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

回答by JasonTrue

While only Twitter can answer that, you're essentially asking the wrong question. You should be asking yourself what business or technical problem made Scala useful to Twitter.

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

In fact, if you read about Twitter's integration of code in Scala, you'll see that they didn't just toss out Rails; they built systems to support a portion of their application in Scala and refactored existing code to talk to services built in Scala.

事实上，如果您阅读Twitter 将代码集成到 Scala 中的内容，您会发现他们不仅仅抛弃了 Rails；他们构建系统以支持 Scala 中的部分应用程序，并重构现有代码以与 Scala 中构建的服务进行通信。

At some point, their primary technical concern ceased to be about the web app itself and became more about messaging and notifications. Groovy and Grails wouldn't have helped them solve that problem much better (or perhaps ANY better) than Rails. Scala, and other functional languages, make it easier to reason about highly concurrent problems by minimizing mutable state. It provides an actor model for concurrency problems that makes it easier to scale certain categories of applications to multiple processors and multiple servers.

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

This is essentially the reason why you should have more than one tool in your reperttheitroade. Some problems aren't as simple as storing data and presenting it. You can get pretty far with pure Ruby tools, but there are still some practical limits when dealing with problems that either need threading or distribution across multiple machines.

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

They might as easily have chosen Erlang or even F# given a different set of team members or motivations. But another web framework would have likely provided little benefit at a far more substantial cost when their problem wasn't really at the front end.

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

回答by Antonin Brettsnajdr

Maybe you can find your answers here: http://www.artima.com/scalazine/articles/twitter_on_scala.html

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

Paragraph "Reliable, high performance code" catches it pretty well :-).

段落“可靠的高性能代码”很好地抓住了它:-)。

Bill Venners: I'm curious, and the Ruby folks will want it spelled out: Can you elaborate on what you felt the Ruby language lacked in the area of reliable, high performance code?

Steve Jenson: One of the things that I've found throughout my career is the need to have long-lived processes. And Ruby, like many scripting languages, has trouble being an environment for long lived processes. But the JVM is very good at that, because it's been optimized for that over the last ten years. So Scala provides a basis for writing long-lived servers, and that's primarily what we use it for at Twitter right now. Another thing we really like about Scala is static typing that's not painful. Sometimes it would be really nice in Ruby to say things like, here's an optional type annotation. This is the type we really expect to see here. And we find that really useful in Scala, to be able to specify the type information.

Robey Pointer: Also, Ruby doesn't really have good thread support yet. It's getting better, but when we were writing these servers, green threads were the only thing available. Green threads don't use the actual operating system's kernel threads. They sort of emulate threads by periodically stopping what they are doing and checking whether another “thread” wants to run. So Ruby is emulating threads within a single core or a processor. We wanted to run on multi-core servers that don't have an infinite amount of memory. And if you don't have good threading support, you really need multiple processes. And because Ruby's garbage collector is not quite as good as Java's, each process uses up a lot of memory. We can't really run very many Ruby daemon processes on a single machine without consuming large amounts of memory. Whereas with running things on the JVM we can run many threads in the same heap, and let that one process take all the machine's memory for its playground.

Alex Payne: I'd definitely want to hammer home what Steve said about typing. As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models. I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly. You're checking for null values all over the place. There's lots of calls to Ruby's kind_of? method, which asks, “Is this a kind of User object? Because that's what we're expecting. If we don't get that, this is going to explode.” It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now.

Bill Venners：我很好奇，Ruby 的人会希望它详细说明：您能详细说明您认为 Ruby 语言在可靠、高性能代码方面的不足之处吗？

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

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

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

回答by Vladimir Dyuzhev

In the hindsight they may present it as a rational decision, but we know... Scala was just a cool new toy.

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

There cannot be any rational reason to choose new, unproven, untested in production system for your implementation.

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

Developers are famous for being inconsiderate to risks. These guys got lucky. We do not hear of those who wasn't though.

开发人员以不考虑风险而闻名。这些人走运了。我们没有听说那些不是。