Scala масштабируется лучше, чем другие языки JVM?

Question

Вот единственный способ, которым я знаю, чтобы спросить это в данный момент. Как понять это, Scala использует виртуальную машину Java. Я думал, что Джруби тоже. Твиттер переключил свое промежуточное ПО на Scala. Могли ли они сделать то же самое и использовать Джруби?

Могли ли они начать с Jruby с самого начала, и у них не было проблем с масштабированием, из-за которых они перешли из Ruby в Scala? Разве я не понимаю, что такое Джруби? Я предполагаю, что, поскольку Jruby может использовать Java, он масштабируется там, где Ruby не будет.

В этом случае все сводится к статическим или динамическим типам?

Answer 1

Scala является «масштабируемой» в том смысле, что язык может быть улучшен библиотеками таким образом, что расширения выглядят так, как будто они являются частью языка. Вот почему актеры выглядят как часть языка, или почему BigInt выглядит как часть языка.

Это также относится к большинству других языков JVM. Он не применяется к Java, потому что он имеет особый подход к базовым типам (Int, Boolean и т. Д.), К операторам, громоздкому синтаксису, который проясняет, что встроено в язык, что такое библиотека и т. Д.

Теперь Scala более эффективен, чем динамические языки на JVM , потому что JVM не поддерживает их. Динамические языки в JVM должны прибегать к рефлексии, которая очень медленная.

Answer 2

Нет, не совсем. Дело не в том, что JVM каким-то образом волшебен и делает вещи масштабируемыми своими магическими силами; Дело в том, что Scala как язык спроектирован так, чтобы помогать людям создавать масштабируемые системы. То, что это на вершине JVM, почти случайно.

Answer 3

Вы должны выделить различные значения масштабирования:

1. Масштабирование с точки зрения увеличения количества запросов в секунду, которое может быть обработано с пропорциональным увеличением аппаратного обеспечения.
2. Масштабирование с точки зрения расширения базы кода без превращения ее в запутанный беспорядок

Scala помогает по первому пункту, потому что он компилируется в байт-код Java, который действительно похож на Java, и, следовательно, обычно имеет ту же производительность, что и Java. Я говорю «обычно», потому что в Scala есть некоторые случаи, когда идиоматическая Scala приводит к большому объему бокса, в отличие от идиоматической Java (это планируется изменить в Scala 2.8).

Производительность, конечно, отличается от масштабирования. Эквивалентный код, написанный на JRuby, также будет масштабироваться, но наклон линии будет круче - вам потребуется больше оборудования для обработки того же количества запросов, но форма линии будет такой же. Но с практической точки зрения производительность помогает, потому что вы редко можете линейно масштабировать масштаб при добавлении ядра или особенно серверов, а более высокая производительность замедляет скорость, с которой вы должны добавлять емкость.

Scala помогает со вторым моментом, потому что он имеет выразительную систему типов с принудительной компиляцией во время компиляции и предоставляет множество других средств для управления сложностью вашего кода, таких как миксины. Вы можете написать код спагетти на любом языке, но компилятор Scala сообщит вам, когда некоторые из лапш сломаны, а с JRuby вам придется полагаться исключительно на тесты. Я лично обнаружил, что для меня Python разбивается примерно на 1000 тесно связанных между собой LOC, и в этот момент мне нужно реорганизовать либо существенно сократить LOC, либо сделать структуру более модульной. Конечно, этот рефакторинг был бы хорошей идеей независимо от того, на каком языке вы говорите, но иногда сложность присуща. Работать с большим количеством тесно связанных LOC нелегко ни на одном языке, но в Scala это намного проще, чем в Python, и я думаю, что аналогия распространяется и на Ruby / JRuby.

Answer 4

Я действительно не думаю, что язык - самая большая проблема здесь. Twitter вырос безумно быстро, что всегда приводит к путанице в коде. И если вы делаете переписывание, это хорошая идея, чтобы перейти на другой язык - который запрещает вам снова создавать свои собственные ошибки и / или «использовать некоторые части». Кроме того, Ruby на самом деле не предназначен для такой тяжелой обработки данных, которую делает бэкэнд Twitter. Внешний интерфейс остается Ruby, поэтому они все еще используют его.

Answer 5

Масштабируемость не является наследственной возможностью языка. Вы говорите о скорости.

Лучше задать вопрос: «Почему Scala быстрее других языков JVM (или это так)?». Как уже отмечали другие, это статический и динамический язык.

Answer 6

Scala - статически типизированный язык. JRuby динамически набирается. Вот почему Scala быстрее, чем JRuby, хотя оба работают на JVM. JRuby должен выполнять большую работу во время выполнения (разрешение методов и т. Д.), Которую Scala выполняет во время компиляции. Несмотря на это, JRuby - очень быстрая реализация Ruby.

Answer 7

В комментариях к этому посту есть интересная дискуссия от самих разработчиков Twitter. Они оценили различные варианты и решили реализовать бэкэнд в Scala, потому что: он работал быстрее, чем альтернативы Ruby / JRuby, и они чувствовали, что могут извлечь выгоду из статической типизации.