Scala 的扩展性是不是优于其他 JVM 语言？

Posted 2023-02-23

【中文标题】Scala 的扩展性是不是优于其他 JVM 语言？

【英文标题】：Does Scala scale better than other JVM languages?Scala 的扩展性是否优于其他 JVM 语言？

【发布时间】：2010-10-31 01:04:15

【问题描述】：

这是我目前知道的唯一方法。理解它 Scala 使用 Java 虚拟机。我认为Jruby也是。 Twitter 将其中间件切换到了 Scala。 他们可以做同样的事情并使用 Jruby 吗？

他们是否可以从 Jruby 开始，并且没有遇到导致他们从 Ruby 迁移到 Scala 的缩放问题？我不明白 Jruby 是什么吗？我假设因为 Jruby 可以使用 Java，所以它会在 Ruby 无法使用的地方进行扩展。

在这种情况下，这一切都归结为静态类型与动态类型吗？

【参考方案1】：

不，不是真的。这并不是说 JVM 具有某种魔力，并通过它的魔力使事情规模化。 Scala，作为一种语言，旨在帮助人们编写可扩展的系统。它位于 JVM 之上几乎是偶然的。

【讨论】：

所以当有人说 java 扩展性很好是因为它是一种高级语言？

我不明白。我认为这与其说是语言，不如说是解释器、编译器等。你不会这么说的。

你说得对，我说的恰恰相反：语言的结构会影响人们用它表达的概念以及他们表达它们的方式，就像在自然语言符号学中一样。编译器/解释器很重要，不要误会我的意思，但这不是 Scala 具有它所具有的属性的原因，或者在 JVM 之上构建的每一种 Tom-Dick-and-Harry 语言都将是世界闻名的可扩展性的典范。

我认为你们将性能和可扩展性混为一谈。它们是不同的东西。

我不知道。我只是在这方面的表面水平（因此我的问题）。我所知道的是，Twitter 在中间件上从 Ruby 转向了 Scala，因为它“可扩展”。我读到 Scala 使用 JVM，所以我想知道他们不是从也使用 JVM 的 Jruby 开始的。

【参考方案2】：

Scala 是一种静态类型语言。 JRuby 是动态类型的。这就是为什么 Scala 比 JRuby 快的原因，尽管两者都运行在 JVM 上。 JRuby 必须在运行时完成大量工作（方法解析等），而 Scala 在编译时完成。不过，就其价值而言，JRuby 是一个非常快速的 Ruby 实现。

【讨论】：

这是真的吗？这是它表现更好的唯一原因吗？

性能复杂，但这无疑是Scala性能更好的主要原因。

不，这不是绝对的事实。 jvm 本身就是一个很好的反例。你可以在运行时做很多编译时做不到的优化。

不提前编译处理这个吗？

你说的是 jit 吗？如果是这样，那也可以在动态语言上完成。

【参考方案3】：

Scala 是“可扩展的”，因为 语言 可以通过库以使扩展看起来像是该语言的一部分的方式进行改进。这就是为什么演员看起来像语言的一部分，或者为什么 BigInt 看起来像语言的一部分。

这也适用于大多数其他 JVM 语言。它不适用于 Java，因为它对基本类型（Int、Boolean 等）、运算符、繁琐的语法进行了特殊处理，明确了语言中构建了什么以及什么是库等。

现在，Scala 比 JVM 上的动态语言性能更高，因为 JVM 不支持它们。 JVM上的动态语言不得不求助于反射，速度很慢。

【讨论】：

+1，这个答案比我的更准确。 Fwiw，JVM 对动态语言的支持越来越好。

JRuby 的设计者受限于他们正在实现动态类型的 Ruby。 Scala 是静态类型的。静态类型意味着每个标识符和表达式的类型在编译时是已知的，使计算机能够为类创建固定的方法调度或动态调度。在动态语言的情况下——在 JVM 上！ -- 在编译时类型未知的情况下，每个方法调用的代码必须利用反射来搜索对象上的方法名称，并且只有他们调用它。顺便说一句，这与动态调度不同。

“表演”？我会编辑这个，但我认为你刚刚发明了一个很棒的新词。

是的，不是英文单词。现在想不出合适的翻译。 :-) 我最终会编辑这个。或者有新词的徽章吗？ :-) :-)

对于计算机编程，我们已经有一个虚构的词：“性能”

【参考方案4】：

this post 的 cmets 中有来自 Twitter 开发人员自己的有趣讨论。 他们评估了不同的选项并决定在 Scala 中实现后端，因为：它比 Ruby/JRuby 替代方案运行得更快，而且他们认为可以从静态类型中受益。

【讨论】：

那里的帖子非常有趣。 Charles Nutter（Jruby 项目负责人）的那句话对他们不选择 Jruby 感到非常痛苦。

【参考方案5】：

我真的不认为语言是这里最大的问题。 Twitter 发展得非常快，这总是导致代码混乱。而且，如果您进行重写，那么使用不同的语言是一个好主意 - 这会阻止您再次构建自己的错误和/或“重用某些部分”。此外，Ruby 并不真正适用于 twitter 后端所做的那种繁重的数据处理。 前端仍然是 Ruby，所以他们仍然使用它。

【参考方案6】：

可扩展性不是继承语言的能力。你说的是速度。

一个更好的问题应该是“为什么 Scala 比其他 JVM 语言（或者它）更快？”。正如其他人所指出的，这是静态语言与动态语言的区别。

【参考方案7】：

你必须区分缩放的不同含义：

随着硬件的成比例增加，每秒可以处理的请求数量增加 在扩展代码库方面进行扩展，而不会使代码库变得一团糟

Scala 在第一点上有所帮助，因为它编译为与 Java 非常相似的 Java 字节码，因此通常具有与 Java 相同的性能。我说“通常”，因为 Scala 在某些情况下，惯用的 Scala 会导致发生大量的装箱，而惯用的 Java 不会（这将在 Scala 2.8 中发生变化）。

性能当然不同于缩放。用 JRuby 编写的等效代码也可以扩展，但线的斜率会更陡 - 您需要更多硬件来处理相同数量的请求，但线的形状会相同。但从更实际的角度来看，性能会有所帮助，因为在添加核心或特别是服务器方面，您很少能以完美的线性方式进行扩展，而拥有更好的性能会减慢您必须添加容量的速度。

Scala 对第二点有所帮助，因为它具有表达能力强的编译时强制类型系统，并且它提供了许多其他方法来管理代码的复杂性，例如 mixin。您可以用任何语言编写意大利面条式代码，但 Scala 编译器会告诉您何时出现问题，而使用 JRuby，您将不得不完全依赖测试。我个人发现，对我而言，Python 在大约 1000 个密切相关的 LOC 处发生故障，我必须重构以大幅减少 LOC 或使结构更加模块化。当然，无论您的语言是什么，这种重构都是一个好主意，但有时复杂性是固有的。处理大量紧密耦合的 LOC 在任何语言中都不容易，但在 Scala 中比在 Python 中要容易得多，而且我认为这个类比也可以扩展到 Ruby/JRuby。