Scala是否比其他JVM语言更好地扩展?

时间:2009-06-03 16:10:43

标签: ruby scala twitter scalability jruby

目前我知道这是唯一的问题。理解它Scala使用Java虚拟机。我以为Jruby也是。 Twitter将其中间件转换为Scala。 他们可以做同样的事情并使用Jruby吗?

他们是否已经开始使用Jruby,而不是因为他们的缩放问题导致他们首先从Ruby迁移到Scala?我不明白Jruby是什么?我假设因为Jruby可以使用Java,所以它会扩展到Ruby不会的地方。

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

7 个答案:

答案 0 :(得分:39)

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

这也适用于大多数其他JVM语言。它不适用于Java,因为它对运算符的基本类型(Int,Boolean等)有特殊处理,繁琐的语法清楚地表明了语言中构建的内容以及库是什么等。

现在,Scala比JVM 上的动态语言更具性能,因为JVM不支持它们。 JVM上的动态语言必须采用反射,这非常慢。

答案 1 :(得分:11)

不,不是真的。并不是说JVM在某种程度上是神奇的,并且通过它的神奇力量使事物变得规模化; Scala作为一种语言,其架构旨在帮助人们编写可扩展的系统。它位于JVM之上几乎是偶然的。

答案 2 :(得分:5)

我真的不认为语言是这里最大的问题。 Twitter变得非常快,总是会导致代码混乱。如果你进行重写,最好选择不同的语言 - 禁止你再次构建自己的错误和/或“重用某些部分”。此外,Ruby并不是真正意味着Twitter后端所做的那种繁重的数据处理。 前端仍然是Ruby,所以他们仍然使用它。

答案 3 :(得分:5)

你必须分出不同的缩放含义:

  1. 按比例增加每秒可以通过硬件按比例增加处理的请求数量
  2. 在增加代码库方面进行扩展而不会成为纠结的混乱
  3. Scala帮助第一点,因为它编译为与Java非常相似的Java字节码,因此通常具有与Java相同的性能。我说“通常”,因为Scala有些情况下惯用的Scala导致大量的拳击发生在惯用Java不会发生的情况下(这将在Scala 2.8中发生变化)。

    性能当然与缩放不同。用JRuby编写的等效代码也可以扩展,但是线的斜率会更陡峭 - 你需要更多的硬件来处理相同数量的请求,但是线的形状是相同的。但从更实际的角度来看,性能有所帮助,因为在添加核心或特别是服务器方面很少能够以完全线性的方式扩展,并且具有更好的性能会降低您必须增加容量的速度。

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

答案 4 :(得分:4)

Scala是一种静态类型语言。 JRuby是动态类型的。这就是为什么Scala比JRuby快,即使它们都运行在JVM上。 JRuby必须在运行时(方法解析等)做很多工作,Scala在编译时完成这项工作。但是,对于它的价值,JRuby是一个非常快速的Ruby实现。

答案 5 :(得分:4)

可伸缩性不是继承语言功能。你说的是速度。

更好的问题是“为什么Scala比其他JVM语言更快(或者是它)?”。正如其他人所指出的那样,它是一种静态与动态的语言。

答案 6 :(得分:3)

Twitter开发人员自己在this post的评论中进行了一次有趣的讨论。 他们评估了不同的选项,并决定在Scala中实现后端,因为:它比Ruby / JRuby替代品跑得更快,他们觉得他们可以从静态类型中受益。