Scala 的扩展性是否比其他 JVM 语言更好？
这是我目前知道的唯一提问方式。 据了解，Scala 使用 Java 虚拟机。 我以为朱比也这么做了。 Twitter 将其中间件切换为 Scala。 他们是否可以做同样的事情并使用 Jruby？
他们是否可以从 Jruby 开始，而不会遇到导致他们从 Ruby 迁移到 Scala 的扩展问题？ 我不明白Jruby是什么吗？ 我假设因为 Jruby 可以使用 Java，所以它可以在 Ruby 无法扩展的地方进行扩展。
在这种情况下，这一切都归结为静态类型与动态类型吗？
Here is the only way I know to ask it at the moment. As Understand it Scala uses the Java Virtual Machine. I thought Jruby did also. Twitter switched its middleware to Scala. Could they have done the same thing and used Jruby?
Could they have started with Jruby to start with and not had their scaling problems that caused them to move from Ruby to Scala in the first place? Do I not understand what Jruby is? I'm assuming that because Jruby can use Java it would have scaled where Ruby would not.
Does it all boil down to the static versus dynamic types, in this case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
不，不是真的。 这并不是说 JVM 有某种魔力，可以通过它的魔力使事物扩展；而是说 JVM 具有一定的魔力。 Scala 作为一种语言，旨在帮助人们编写可扩展的系统。 它位于 JVM 之上几乎是偶然的。
No, not really. It's not that the JVM is somehow magic and makes things scale by its magic powers; it's that Scala, as a language, is architected to help people write scalable systems. That it's on top of the JVM is almost incidental.
Scala 是“可扩展的”，因为库可以对语言进行改进，使扩展看起来像是语言的一部分。 这就是为什么 actor 看起来像是语言的一部分，或者为什么 BigInt 看起来像是语言的一部分。
这也适用于大多数其他 JVM 语言。 它不适用于Java，因为它对其基本类型（Int、Boolean 等）、运算符、繁琐的语法（明确语言中内置的内容和库等）有特殊处理。
现在，Scala 更性能优于 JVM 上的动态语言，因为 JVM 不支持它们。 JVM 上的动态语言必须借助反射，速度非常慢。
Scala is "scalable" in the sense that the language can be improved upon by libraries in a way that makes the extensions look like they are part of the language. That's why actors looks like part of the language, or why BigInt looks like part of the language.
This also applies to most other JVM languages. It does not apply to Java, because it has special treatment for it's basic types (Int, Boolean, etc), for operators, cumbersome syntax that makes clear what is built in the language and what is library, etc.
Now, Scala is more performatic than dynamic languages on the JVM because the JVM has no support for them. Dynamic languages on JVM have to resort t reflection, which is very slow.
您必须区分扩展的不同含义：
Scala 在第一个方面有所帮助之所以如此，是因为它编译为与 Java 非常相似的 Java 字节码，因此通常具有与 Java 相同的性能。 我说“通常”是因为 Scala 在某些情况下，惯用的 Scala 会导致大量装箱，而惯用的 Java 则不会（这将在 Scala 2.8 中改变）。
性能当然不同于缩放。 用 JRuby 编写的等效代码也可以扩展，但线的斜率会更陡 - 您需要更多的硬件来处理相同数量的请求，但线的形状将是相同的。 但从更实际的角度来看，性能是有帮助的，因为在添加核心或特别是服务器方面，您很少能够以完美的线性方式进行扩展，并且更好的性能会减慢您必须添加容量的速度。
Scala 有助于解决第二点，因为它具有富有表现力的编译时强制类型系统，并且提供了许多其他方法来管理代码的复杂性，例如 mixin。 您可以用任何语言编写面条式代码，但 Scala 编译器会告诉您面条何时损坏，而使用 JRuby 时您必须完全依赖测试。 我个人发现，对我来说，Python 在大约 1000 个密切相关的 LOC 处崩溃，此时我必须重构以大幅减少 LOC 或使结构更加模块化。 当然，无论您使用哪种语言，这种重构都是一个好主意，但有时复杂性是固有的。 在任何语言中处理大量紧密耦合的 LOC 都不容易，但在 Scala 中比在 Python 中容易得多，而且我认为这种类比也适用于 Ruby/JRuby。
You have to separate out different meanings of scaling:
Scala helps on the first point because it compiles to Java bytecode that's really similar to Java, and therefore usually has the same performance as Java. I say "usually," because Scala there are some cases where idiomatic Scala causes large amount of boxing to take place where idiomatic Java would not (this is slated to change in Scala 2.8).
Performance is of course different than scaling. Equivalent code written in JRuby would scale just as well, but the slope of the line would be steeper - you'd need more hardware to handle the same number of requests, but the shape of the line would be the same. But from a more practical perspective the performance helps because you rarely can scale in a perfectly linear fashion with respect to adding core or especially servers and having better performance slows the rate at which you have to add capacity.
Scala helps with the second point because it has an expressive, compile-time enforced type system and it provides a lot of other means for managing the complexity of your code, such as mixins. You can write spaghetti code in any language, but the Scala compiler will tell you when some of the noodles are broken while with JRuby you'll have to rely solely on tests. I've personally found that for me Python breaks down at about 1000 closely related LOCs, and which point I have to refactor to either substantially reduce of the LOCs or make the structure more modular. Of course this refactoring would be a good idea regardless of what your language, but occasionally the complexity is inherent. Dealing with a large number of tightly couple LOCs isn't easy in any language, but it is much easier in Scala than it is in Python, and I think the analogy extends to Ruby/JRuby as well.
我真的不认为语言是这里最大的问题。 Twitter 的发展速度非常快，这总是会导致代码混乱。 如果您进行重写，最好选择不同的语言 - 这会阻止您再次犯下自己的错误和/或“重用某些部分”。 此外，Ruby 并不是真正适合 Twitter 后端那样的繁重数据处理。
前端仍然是 Ruby，所以他们仍然使用它。
I don't really think that the language is the biggest problem here. Twitter grew insanely fast, which always leads to a code mess. And if you do a rewrite, it is a good idea to go for a different language - that bars you from building your own mistakes again and/or to "reuse some parts". Also, Ruby is not really meant for that kind of heavy data handling that the twitter backend does.
The frontend remains Ruby, so they still use it.
Scala 是一种静态类型语言。 JRuby 是动态类型的。 这就是为什么 Scala 比 JRuby 更快，尽管两者都运行在 JVM 上。 JRuby 必须在运行时做很多 Scala 在编译时做的工作（方法解析等）。 不过，就其价值而言，JRuby 是一个非常快的 Ruby 实现。
Scala is a statically typed language. JRuby is dynamically typed. That is why Scala is faster than JRuby, even though both run on the JVM. JRuby has to do a lot of work at runtime (method resolution, etc.) that Scala does at compile-time. For what it's worth, though, JRuby is a very fast Ruby implementation.
可扩展性不是继承的语言功能。 你说的是速度。
更好的问题是“为什么 Scala 比其他 JVM 语言更快（或者确实如此）？”。 正如其他人指出的那样，这是静态语言与动态语言的问题。
Scalability is not an inherit language capability. You are talking about speed.
A better question to ask would be "Why is Scala faster than other JVM languages (or is it)?". As others have pointed out, it's a static vs. dynamic language thing.
Twitter 开发者自己在 这篇文章。
他们评估了不同的选项并决定在 Scala 中实现后端，因为：它比 Ruby/JRuby 替代方案运行得更快，并且他们认为可以从静态类型中受益。
There's an interesting discussion from the Twitter developers themselves in the comments of this post.
They've evaluated the different options and decided to implement the back-end in Scala because: it ran faster than the Ruby/JRuby alternatives and they felt they could benefit from static typing.