Groovy и Grails vs Scala, почему Twitter выбирает Scala?

Ответ 1

Возможно, вы можете найти свои ответы здесь: http://www.artima.com/scalazine/articles/twitter_on_scala.html

Параграф "Надежный, высокопроизводительный код" очень хорошо его поймает: -).

Bill Venners: Мне любопытно, и люди из Ruby захотят, чтобы это было написано out: Можете ли вы рассказать о том, что, по вашему мнению, не было в рубиновом языке? область надежного высокопроизводительного кода?

Стив Дженсон. Одна из вещей, которые я обнаружил на протяжении всей моей карьеры, - это необходимость иметь долгоживущие процессы. И Ruby, как и многие скрипты языков, не может быть средой для долгоживущих процессов. Но JVM очень хорош в этом, потому что он был оптимизирован для этого за последние десять лет. Таким образом, Scala обеспечивает основу для написания долгоживущие серверы, и это в первую очередь то, что мы используем для Twitter прямо сейчас. Другое, что нам действительно нравится в Scala, - это статическая типизация это не больно. Иногда в Ruby было бы очень приятно сказать такие вещи, как heres, необязательная аннотация типа. Это тип, который мы действительно ожидаем увидеть здесь. И мы находим, что это действительно полезно в Scala, чтобы быть в состоянии указать информацию о типе.

Roboy Pointer. Кроме того, Ruby не имеет хорошей поддержки потоков. Это стало лучше, но когда мы писали эти серверы, зеленый потоки были единственной доступной. Зеленые нити не используют фактические потоки ядра операционной системы. Они вроде эмулируют потоки периодически останавливая то, что они делают, и проверяя, другой "поток" хочет запустить. Итак, Ruby эмулирует потоки в пределах одноядерный процессор или процессор. Мы хотели работать на многоядерных серверах которые не имеют бесконечного объема памяти. И если у вас нет хорошая поддержка потоковой передачи, вам действительно нужно несколько процессов. А также потому что сборщик мусора Rubys не так хорош, как Javas, каждый процесс использует много памяти. Мы не можем запустить очень много Ruby демонов на одной машине без потребления больших объемов памяти. В то время как при запуске на JVM мы можем запускать много потоки в одной и той же куче, и пусть один процесс принимает все памяти машин для игровой площадки.

Алекс Пейн: Я определенно хочу забить дом, что сказал Стив типирование. По мере роста нашей системы, большая часть логики в нашей системе Ruby тип репликации системы типов, либо в наших модульных тестах, либо как валидации на моделях. Я думаю, что это может быть просто свойство систем на динамических языках, что в конечном итоге вы в конечном итоге переписываете ваш собственный тип системы, и вы вроде делаете это плохо. Вы проверяете нулевые значения по всему месту. Theres много звонков в Rubys вид? метод, который спрашивает: "Является ли это своего рода объектом User? вот чего ожидали. Если мы этого не получим, это будет взорваться". Жаль, что нужно написать все это, когда есть решение, существовавшее в мире языков программирования для десятилетий.

Ответ 2

Хотя только Твиттер может ответить на этот вопрос, вы, по сути, задаете неправильный вопрос. Вы должны спрашивать себя, какая бизнес-или техническая проблема сделана Scala полезной для Twitter.

Фактически, если вы прочитаете о интеграции кода Twitter в Scala, вы увидите, что они не просто выбросили Рельсы; они построили системы для поддержки части своего приложения в Scala и реорганизовали существующий код, чтобы поговорить с службами, встроенными в Scala.

В какой-то момент их основная техническая проблема перестала быть о самом веб-приложении и стала больше о сообщениях и уведомлениях. Groovy и Grails не помогли бы им решить эту проблему намного лучше (или, возможно, ЛЮБОЙ лучше), чем Rails. Scala и другие функциональные языки упрощают рассуждение о проблемах с высокой степенью параллелизма, сводя к минимуму изменяемое состояние. Он обеспечивает актерскую модель для проблем concurrency, которая упрощает масштабирование определенных категорий приложений на нескольких процессорах и нескольких серверах.

Это по сути является причиной того, что у вас должно быть больше одного инструмента в вашем репертуаре. Некоторые проблемы не так просты, как хранение данных и их представление. Вы можете получить довольно далеко с чистыми инструментами Ruby, но есть все еще некоторые практические ограничения при решении проблем, которые либо нуждаются в потоковом или распределении между несколькими машинами.

Они могли бы легко выбрать Erlang или даже F #, учитывая другой набор членов команды или мотивацию. Но другая веб-структура, скорее всего, принесла бы небольшую выгоду гораздо более значительным издержкам, когда их проблема не была на самом деле в передней части.

Ответ 3

В ретроспективе они могут представить это как рациональное решение, но мы знаем... Scala была просто классной новой игрушкой.

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

Разработчики славятся тем, что не склонны к рискам. Этим парням повезло. Мы не слышим о тех, кто не был.