考虑到不同的团队成员或动机，他们可能很容易选择 Erlang 甚至 F#。但是，当问题并非真正出现在前端时，另一个 Web 框架可能会以更大的成本提供很少的好处。
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.
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.
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.
This is essentially the reason why you should have more than one tool in your repertoire. 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.
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.
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.
发布评论
评论（3）
虽然只有 Twitter 可以回答这个问题，但你基本上问错了问题。您应该问自己是什么业务或技术问题使 Scala 对 Twitter 有用。
事实上，如果您阅读有关 Twitter 在 Scala 中集成代码，您就会看到他们不只是抛弃 Rails；他们构建了系统来支持 Scala 中的部分应用程序，并重构了现有代码以与 Scala 中构建的服务进行交互。
在某种程度上，他们的主要技术关注点不再是网络应用程序本身，而是更多地关注消息传递和通知。 Groovy 和 Grails 不会比 Rails 更好地（或者可能更好）帮助他们解决这个问题。 Scala 和其他函数式语言通过最小化可变状态使推理高度并发问题变得更加容易。它为并发问题提供了一个参与者模型，可以更轻松地将某些类别的应用程序扩展到多个处理器和多个服务器。
从本质上讲，这就是为什么您应该拥有不止一种工具的原因。有些问题并不像存储数据和呈现数据那么简单。使用纯 Ruby 工具可以取得很大的成果，但在处理需要线程或跨多台机器分布的问题时仍然存在一些实际限制。
考虑到不同的团队成员或动机，他们可能很容易选择 Erlang 甚至 F#。但是，当问题并非真正出现在前端时，另一个 Web 框架可能会以更大的成本提供很少的好处。
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.
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.
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.
This is essentially the reason why you should have more than one tool in your repertoire. 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.
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.
也许您可以在这里找到答案：http://www.artima.com/scalazine/articles/twitter_on_scala.html< /a>
“可靠、高性能的代码”段落很好地表达了这一点:-)。
Maybe you can find your answers here: http://www.artima.com/scalazine/articles/twitter_on_scala.html
Paragraph "Reliable, high performance code" catches it pretty well :-).
事后看来，他们可能会将其视为一个理性的决定，但我们知道……Scala 只是一个很酷的新玩具。
没有任何合理的理由为您的实施选择新的、未经证实的、未经测试的生产系统。
开发商以不考虑风险而闻名。这些家伙很幸运。我们没有听说过那些没有的人。
In the hindsight they may present it as a rational decision, but we know... Scala was just a cool new toy.
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.