Миграция с Ruby

    imageУверен, что на Хабре обитает огромное число юзеров, облизывающихся при чтении описаний технологий и архитектур, используемых в молодых, динамичных и, что наиболее важно, быстрорастущих в своей пользовательской базе, компаний. К сожалению, относительно небольшое количество наших соотечественников работает в таких компаниях по всему миру, а те, кто все-таки трудится во внутренней кухне, связаны различными условиями трудовых договоров или банальным NDA, запрещающим сливать публике самые интересные подробности. Тем не менее, я лично знаю большое количество специалистов, особенно заинтересованных в высоких нагрузках и не знающих, где получить эту информацию из первых рук.

    Эту проблему можно решить единственным способом — предоставить слово кому-то из менеджеров отдела разработки или любому другому человеку, занимающему адекватно высокий пост и разбирающемуся в разработке, а после — тянуть, тянуть из него все подробности. Примерно так поступили в Information Queue, опросив одного из инженеров Twitter'а — Эвана Уивера (Evan Weaver) о том, почему компания так долго развивавшаяся на «рельсах», решила переключиться на использование других технологий и какие это имело последствия.

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

    Итак, история начинается в прошлом году, когда Twitter анонсировал изменения в архитектуре бэкэнда (message queue), а так же заявил о намерении переписать Twitter Storage на Scala, а весной началась работа по переписыванию всего поискового движка. Как часть этих изменений, БД MySQL (лежавшая в основе поиска) была заменена Lucene. И, наконец, совсем недавно команда разработчиков заявила о замене Ruby on Rails в области поиска — на его место встал Java-сервер, который они сами называют Blender. Результатом этой замены стало трехкратное снижение задержки при выполнении поискового запроса.

    Overview


    Один из первых выводов, который можно сделать глядя на общую архитектуру Twitter'а заключается в том, что многие решения его разработчиков кажутся идеально прагматичными. Например, в бэкэнде продукта используется как MySQL, так и распределенная БД Cassandra. Немногие знают о собственной разработке инженеров Twitter'а: Gizzard — фреймворке, используемом для создания распределённых хранилищ на основе БД MySQL. По словам Уивера: «он в основном используется для высоко-структурированных данных (SLA-data) так как не является относительно гибким».

    Все данные реального времени получаются либо из Gizzard/MySQL, либо из Cassandra. Так же в архитектуре активно используется стек для распределенных вычислений Hadoop для оффлайн калькуляций, в онлайне же используется система, построенная с помощью key-value базы данных Redis и вышеупомянутого Gizzard.

    Взаимосвязь между уровнями фронтэндом и бэкэндом реализована за счет разработки компании Facebook — Thrift (язык описания интерфейсов, используется в качестве RPC) и JSON REST API, используемого во всех «официальных» клиентах от Twitter и новом сайте продукта.

    Languages


    Похожий, прагматичный, подход мы видим и в выборе языков программирования, используемых в компании. Языки первого уровня: JavaScript, Ruby, Scala и Java. Так же работа отчасти поддерживается и на C, однако новые сервисы на нем не пишутся. В общем и целом Эван говорит о переходе на Scala разработчиков со знанием Ruby и использовании Java теми, кто до этого крутился в области C/C++.

    Что касается команды, занимающейся поисковым движком — здесь инструменты диктуют выбор языков. Так как Lucene построен на Java, то и программистам приходится оперировать в первую очередь этим языком.

    Для того чтобы позволять разработчикам самим выбирать идеальный для них язык работы, Twitter вложил много усилий и средств в написание внутренних фреймворков, которые инкапсулируют общие старания всех команд. Finagle (написана на Scala), к примеру — это библиотека для создания асинхронных RPC-серверов и клиентов на Java, Scala или любом другом языке на платформе JVM.

    В то время, как весь бэкэнд постепенно переходит в сторону JVM, фронтэнд (клиентский) код все больше склоняется в сторону использования браузерного JavaScript, уменьшая долю языка Ruby.

    Search: From Ruby to Java



    image

    Переход с Ruby на построенный на Java фреймворк Blender был осуществлен в два шага. Первым была замена существующего MySQL back-end'а на реверсированный индекс в реальном времени, основанный на Lucene и носящий имя Earlybird. Его введение в эксплуатацию удвоило эффективность используемой памяти, а так же гибкость в добавлении различных поисковых фильтров, помогающих поддерживаться быстрорастущий спрос на поиск по продукту. Более подробное описание механизма работы этой части системы описывали инженеры Twitter'а.

    Для того чтобы решить проблему низкой производительности фронтэнда, команда разработчиков построила сервер Java Blender. Blender — это уже упомянутый сервис Thrift и HTTP API, построенный на Netty и масштабируемой клиент-серверной библиотеке NEW I/O (NIO), написанной на Java и позволяющей разрабатывать различные протоколы сервера. Netty дает возможность компании создавать полностью асинхронные сервисы аггрегации, которые могут собирать результаты из нескольких сервисов back-end'а (такие как индексы в реальном времени, топ-твиты и гео-данные).

    Это позволило избежать высоких очередей в I/O, оптимизируя работу CPU и быстрее обрабатывая текущие запросы. Вдобавок, многие запросы в бэкэнде могут быть обработаны параллельно, что значительно снижает задержки.

    image

    Поисковой двигатель Twitter'а является одним из самых загруженных в мире, обрабатывая около миллиарда запросов в сутки. Результат перехода на Blender был просто фантастическим: 95% запросов стали обрабатываться в три раза быстрее, задержка снизилась с 800ms до 250ms, а загрузка процессоров на обоих концах (фронтэнд — бэкэнд) продукта снизилась наполовину. Сегодняшние мощности компании позволяют продукту обрабатывать в 10 раз больше запросов на машину, чем это было до применения этих технологий в архитектуре. Тем самым компания снижает стоимость услуг, необходимых для поддержания всей архитектуры в высоко-производительном состоянии.

    И хотя производительность и масштабируемость были немаловажными проблемами, из-за которых пришлось повышать использование JVM — Эван говорит о том, что инкапсуляция все же является ключевым моментом такого перехода, т.к. текущая архитектура Twitter'а, в общем-то, справляется неплохо. Переход на JVM во многом был продиктован тем, что производительность разработчиков на нем выше и как следствие — выше производительность всего продукта.

    Комбинация фреймворка Ruby on Rails вкупе с БД MySQL была очень популярна для западных стартапов на протяжении последних лет. Плюсы понятны: разработчики могли быстро испытывать новые и простые идеи для того чтобы проверить их отдачу в условиях работы на реальном рынке, где предложение диктуется спросом пользователей. Впрочем, минусы такой связки тоже достаточно очевидны — проблемы масштабируемости и производительности, а так же некоторой незрелости библиотек и инструментов, что касается в первую очередь RoR.

    Спасибо за помощь в точных формулировках хабраюзеру ivaxer

    InfoQ via RRW
    Поделиться публикацией

    Похожие публикации

    Комментарии 82

      +11
      Комбинация Ruby/RoR c *SQL — дает возможность БЫСТРО написать проект. Посмотреть «выстрелит» или нет. И если «все получилось» и нагрузка растет только так — уже можно не торопясь переписывать или оптимизировать «проблемные» части.

        +3
        не менее быстро можно написать и на другом фреймвёрке, с которого миграция на производительную платформу будет легче. например grails + groovy++. вообще, конечно, каждый пишет на чём может и что знает лучше, но всё же лучше ориентироваться на производительные платформы с самого начала. посмотрите как фэйсбук сейчас мучается с php.
          +2
          Назовите мне еще один framework, где есть настолько громадный набор сторонних библиотек (gems). RoR это уже давно конструктор и поэтому позволяет делать сложные сайты просто с фантастической скоростью. Я писал и на grails, и на play!, и на lift. Да, производительность JVM существенно выше, но мне пришлось писать просто дофига всего самому, где на RoR я в 99% подключил бы gem. Ruby потрясающи простой язык, если понять его концепцию. Scala — другой полюс, он гораздо сложнее нативной Java.
            +3
            помнится искали мы что-нибудь для pam авторизации к ror — нашли только две бибилиотеки, одна кривая, другая падает. в groovy/java это уже есть изкаробки. Для grails кучи плагинов есть. Прежде чем ставить минус могли бы конкретно сказать, чего вам не хватает.
              0
              У вас старые данные про RoR. Буквально за последний год очень много добавилось, стало стабильным, включая PAM модули, поиск на Sphinx, ACL, работа с ДОБД, работа с key-value, пейджинг, крамбы и прочее работает весьма надежно. Хотя, безусловно, java всегда впереди планеты всей, например в направлении семантик веба, на роре в сравнении с явой это очень неразвито.
              +12
              Назовите мне еще один framework, где есть настолько громадный набор сторонних библиотек (gems).

              Да легко :)
              Ruby gems: 25,950 gems cut since July 2009
              Perl cpan: 96,766 Perl modules in 22,950 distributions
                +4
                пардон :) про perl забыл — cpan монстр так монстр :)
                  0
                  [irony]что монстр делал?[/irony]
                +3
                >Назовите мне еще один framework, где есть настолько громадный набор сторонних библиотек (gems).

                java/maven
                  +2
                  ага, и через maven можно поставить так же легко sass, haml, devise, coffeescript sprocket и т.д. например для lift?
                    +1
                    А это требуется раз в час?
                +3
                Нет, это не так. Грельсы отстают на много-много лет от рельс.
                  0
                  Смотря с какой стороны посмотреть:

                  1. Grails более идеологически стабилен, там нет таких функциональных скачков от релиза к релизу.

                  2. Grails безумно растёт в Enterprise & Java Shop'ах — мейл лист у него один из самых активных среди Java Web Frameworks. Во многом этому способствует официальная поддержка SpringSource.

                  3. Наряду с проверенными || монстроузными (как кому больше нравится) Spring & Hibernate там появляется поддержка аутентичных Geb, Spock, Gradle.

                  Так что честно говоря не вижу в чём ему отставать если у него совершенно другой рынок и ЦА.
                +2
                А если взять другую популярную связку Python + Django? Интересно, как тут обстоят дела с масштабируемостью и производительностью? И вообще, почему не так часто используют PostgreSQL
                  +4
                  В реальной жизни PostgreSQL используют чаще для технологически-сложных проектов, просто у его пользователей не возникает такого количества проблем, о которых можно писать статьи :)
                    0
                    Если не считать двухсот параметров, которые нужно настраивать после установки.
                      +2
                      what?
                        +3
                        поперхнулся подпрыгнул на стуле, что что?
                      0
                      если сравнивать в ruby 1.8, то быстрее, если с 1.9 — то одинаково, т.е. всё так же далеко от JVM
                        0
                        JRuby не сильно медлее Groovy
                          0
                          для groovy есть groovy++, java и gpars, а про проблемы с jruby написано в оригинальной статье
                            +2
                            В оригинальной статье есть просто конкретное замечание к JRuby со стороны twitter инженеров в том плане, что они написали дохрена всего под CRuby и переписывать не собираются. Я просто указал на то, что нельзя сравнивать Ruby и JVM, так как под JVM есть тот же Groovy, который не быстрее Ruby, исполняющийся под тем же JVM via JRuby, и есть, например, native Java — которая действительно рвет в тряпки Ruby.
                              0
                              >они написали дохрена всего под CRuby и переписывать не собираются.
                              переписали они в контексте оптимизации, ибо нативная ruby/jruby версия тормозит.

                              >так как под JVM есть тот же Groovy, который не быстрее Ruby, исполняющийся под тем же JVM via JRuby
                              как правило он быстрее плюс значительно проще ускоряется методами выше
                      +3
                      С таким подходом легко угробить проект. Представьте себе ситуацию (вполне реальную), что вы анонсировали некий сервис на хабре. Людям оный понравился, включилось сарафанное радио и нагрузка на систему начинает расти экспоненциально, доходя до точки бифуркации, что приводит к обрушению.

                      Для онлайн-проектов первое впечатление самое важное, так что рухнувшая на старте система теряет множество баллов, и за время латания дыр финансово обеспеченные игроки вполне могут успеть выстрелить улучшенным и устойчивым клоном.
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          Проблема в том, что Твиттер изначально развивался не как, например, Фейсбук. Тви делался сначала для быстрого общения друзей (лицокнига начиналась с целого университета), а потом у него не было ограничений на регистрацию (фейсбук распространялся в специально отобранных кампусах), кроме того, его открытое АПИ сильно стимулировало разработчиков, которые дергали сервера сервиса все большим количеством запросов. В результате этого Твиттер периодически рос экспоненциально, показывал кита, падая от нагрузки, отключал поиск… Ситуация требовала вмешательства тактического (чтобы поправить) и стратегического (чтобы справиться с все возрастающими потребностями).

                          В живом цикле разработки все сложнее, чем «сразу сделать все грамотно».
                            0
                            Лучше сделать правильную архитектуру приложение, так чтобы можно было БЫСТРО отмаштабироваться горизонтально и были места для оптимизации. Ну да, сначала можнт быть волна, не будет слэшдот/дигг-эффект — взяли на это время по-большие инстансов, потом все успокоилось и вырубили инстансы лишнии.

                            Но это не означает, что можно сделать все медленно и неправильно оставляя все на рефакторинг и оптимизацию.
                          0
                          > И если «все получилось» и нагрузка растет только так — уже можно не торопясь переписывать или оптимизировать «проблемные» части.

                          Есть оно действительно «выстреливает», то «не торопясь» обычно не получается.
                          +2
                          Видно что переводил человек, не знакомый с Java. NIO это API JavaSE
                            +6
                            Когда число посетителей сравняется с аудиторией твитера, то уже можно и перейти с RoR на что-то другое. Да ну хоть на ассемблере бэкэнд переписать для скорости (-: Человеческие и финансовые ресурсы это позволяют.
                              +2
                              Есть другая сторона медали. Когда приходится проектировать систему, которая неизбежно «выстрелит» (хотя бы по причине вливаемых в рекламу средств), то тайм-аута на переписывание, по мере роста нагрузок, не будет. Так что приходится сразу же планировать масштабируемость и устойчивость. И тут рельсы/джанго годятся только для внутреннего прототипирования.
                                +2
                                Я вас умоляю. Масштабировать проект на рельсах так же просто/сложно как и на других фреймворках. Запустил больше воркеров и всё.

                                Главные сложности возникают всегда с масштабированием БД. А это уж от языка не зависит.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    0
                                    Да, но нафоркать воркеров не стоит ничего (ну кроме самих машин, конечно).

                                    А вот отмасштабировать базу — это СИЛЬНО больнее.

                                    Поэтому мне и кажутся смешными все эти нападки на руби.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        0
                                        Из публичного интерфейса у них только Settings и всякие там Terms, About на RoR остались. Сама же JS-лента твитов напрямую с api.twitter.com работает.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      +1
                                      Но это же не значит что рельсы/эрланг не масштабируются. Масштабируются, просто дороже.
                                      А для монстров рынка (твиттеры там, фейсбуки всякие) общие правила всё равно не действуют.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                        0
                                        Но опять надо сравнивать издержки не только на количество серверов, но и на стоимость работы программистов, причём не только для начальной разработки, но и для поддержки и развития. Грубо говоря, переписывание всего софта на ассемблере освободит просто куеву хучу ресурсов в мировых масштабах, но вот сколько будет стоить его переписать…
                                          +2
                                          Ну не на С++, а на С и не 10к а 6к :) пруф
                                            0
                                            Вот именно, **специфическая задача**. Именно их имеет смысл «переписывать на ассемблере». И то только после результатов профилирования.

                                            Писать же всю систему сразу на С не имеет смысла.

                                            Про десятое правило Гринспуна все помнят? :-)

                                            Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
                                              0
                                              Прогресс не стоит на месте. Есть такой замечательный язык Go, приближённый по быстродействию к C++ и по простоте к Python.
                                      +4
                                      Ну я не знаю ни одной системы, которая на этапе проектирования и запуска «неизбежно выстрелит». Твитер, Фб и т.п. на момент старта вряд ли предполагали такой отклик. С другой стороны, гораздо больше систем, которые задумываются, как вполне себе способные выстрелить, на поверку оказываются никакущими. Пример — гугловские волны. Уж сколько было потрачено человекочасов и средств, а отдача — 0.
                                        +1
                                        Нужно быть немного чокнутым (или гением, что почти одно и то же), чтобы планировать «выстреливание» больших систем. Но помимо них существует множество вариантов, где можно пострелять не слонов, а дичь помельче. Более того, у малых и средних проектов значительно лучше продуманные изначально бизнес планы, а прибыль в очень короткие сроки покрывает все расходы на разработку и обслуживание. Всё же деньги делаются не только на раздувании гигантских пузырей, но и на пускании множества маленьких пузырьков :)
                                        +2
                                        Чего я в тексте пропустил, если я так и не увидел чего-то, кроме повторения факта «Twitter переезжает с руби на java»?

                                        Никакого более детального раскрытия информации, обзоров, цифр и результатов. Это что, пост?
                                          0
                                          Лучше почитать оригинал с InfoQ, там есть цитаты из интервью самого Evan Weaver — на Хабр доехали только выдержки. Ещё можно посмотреть Finagle — на первый взгляд API под Scala гораздо лучше выглядит чем дремучий лес колбеков Node.JS и прочих.
                                          +9
                                          Опять эта тема твиттера и руби… Руби не повезло, что самый большой сайт на нём принадлежит такой странной в техническом отношении компании как твиттер. Несколько примеров… Они написала очередь сообщений на руби (кому вообще могло прийти в голову писать такое на руби во времена черепашьего 1.8?!, причём судя по тестам их реализация была очень далека от оптимальности...) — переписали на скале — по блогам пошли посты на тему; руби дрянь, скала рулит. Переписали поисковую подсистему на JVM с иcпользованием асинхронных запросов к бэкенду через netty — скорость выросла в 10 раз — все снова сделали вывод: руби дрянь, хотя если бы они переписали синхронный код на руби с иcпользованием асинхронности через event_machine, рост производительности был бы таким же огромным.
                                          Плюс странные заявления, что Scala лучше ruby потому, что там статическая типизация, что снижает кол-во ошибок. Надёжность программ со статической типизацией это просто миф, в который верят люди у которых мало опыта с динамическими языками.
                                          Из постов в блогах кажется, что Твиттер компания, где решают все проблемы переходом на новую более модную технологию и написанием своих велосипедов на ней…
                                            0
                                            Из постов в блогах кажется, что Твиттер компания, где решают все проблемы переходом на новую более модную технологию и написанием своих велосипедов на ней…

                                            Но похоже этот подход оправдан, не так ли?
                                              +11
                                              Языки со статической типизацией более надежны, это факт. Их компиляторы устраняют 100% ошибок, связанных с неправильными типами.
                                                –3
                                                У erlang динамическая типизация. Ошибки приведения типов включены в 100% устраняемых ошибок?
                                                «Языки» не могут быть надёжными. Надёжными могут быть программы.
                                                  +1
                                                  Я ему про Фому, он мне про Ерёму.

                                                  При чем тут Эрланг и его динамическая типизация?

                                                    +2
                                                    Вы написали «Языки со статической типизацией более надежны, это факт.» без аргументации. Если бы это было так, то Erlang, специально затачиваемый под надёжные системы, имел бы тоже статическую типизацию.
                                                    Что есть мера надёжности в вашем понимании?
                                                      +1
                                                      Надежность бывает разная, конечно же.

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

                                                        0
                                                        Без динамической типизации в Эрланге было бы трудно сделать горячую замену кода. Тем не менее, он тоже движется в этом направлении: спецификации типов все-таки не зря ввели.
                                                    –2
                                                    Каст в object а потом обратно в неправильный class ваш супер надежный компилятор то же обработает? А если у функции, например, 5 аргументов с типом string и я перепутал местами (или кто то поменял местами) аргументы — то же компилятор найдет? 100% ошибок (я утрирую, конечно) устранят unit test'ы. А их пофигу для чего писать, javascript, ruby, java.
                                                      0
                                                      Каст в object а потом обратно в неправильный class


                                                      Конечно. В С#, например, есть конструкция as. Если этот объект на самом деле не является тем, к чему ты его хочешь привести, она вернет null.

                                                      Пример с перепутанными аргументами вообще не в кассу.
                                                        0
                                                        Комплятор в compile time скажет, что тип неправильный или нет, при использрвании as? Или ошибка будет в runtime (NullPointerException)?

                                                        Почему пример с перепутанными аргументами не в кассу? Разве вызов метода и его проверка в compile time это не часть type safety компилятора?
                                                          +1
                                                          > Комплятор в compile time скажет, что тип неправильный или нет, при использрвании as? Или ошибка будет в runtime (NullPointerException)?

                                                          Надо понимать что as, reinterpret_cast и подобные средства — это средства на крайний случай. В большинстве случаев они не нужны. Если ты хочешь выстрелить себе в ногу (специально), то языки обычно дают тебе такую возможность. И если ты кастишь вниз по иерархии, будь добр проверить на null.

                                                          > Почему пример с перепутанными аргументами не в кассу? Разве вызов метода и его проверка в compile time это не часть type safety компилятора?
                                                          > А если у функции, например, 5 аргументов с типом string

                                                          Ты сам то понял что сказал?
                                                            –4
                                                            Хм, то есть
                                                            «Языки со статической типизацией более надежны, это факт. Их компиляторы устраняют 100% ошибок, связанных с неправильными типами.»
                                                            это лажа, так?

                                                            И компиляторы все же не дают 100% надежность при работе с типами, да? И как только мы кастим к базовому типу, то вся 100% надежность идет к чертям?

                                                            Кто то не врубается что такое type safety, видимо не доходит, что компилятор не может гарантировать 100% отлавливание ошибок работы с типами, потому что в каждом языке есть дыра, когда можно все эти проверки послать к черту.

                                                            Ну если не доходит, то и спор бессмысленный.
                                                              +2
                                                              Вот именно, кто-то не врубается в type safety.

                                                                –4
                                                                Ну успехов в профессиональном развитии, чтож.
                                                                +1
                                                                На это я тебе отвечу так: «сдуру можно и хуй сломать».

                                                                А для нормальных людей компилятор всё гарантирует.
                                                          +7
                                                          Имхо, тут у кого-то с логикой проблемы.

                                                          >Автомобили более безопасны, чем мотоциклы, это факт.
                                                          >А от попадания ядерной бомбы автомобиль защитит? Или от падения со 100 метрового обрыва? Нет! Значит автомобили не безпаснее мотоциклов! От всего вышеперечисленного спасет только радио «Радонеж»

                                                            0
                                                            Ваш пример с кастом на самом деле надуманный. Каст обходится в 99% случаев с помощью параметризированной типизации. А в тот момент, когда параметризированные типы не «срабатывают», надо просто внимательно посмотреть на то, как мы пытаемся их применять. Generics — относительно новое понятие для мейнстрим-разработчиков. Я сам отлично помню, как путался с ними лет пять назад. Сегодня же единственные случаи когда мне приходится использовать cast — это работа со старыми или плохо адаптированными к generics библиотеками.

                                                            Самый возмутительный пример: в JPA метод getResultsList() объекта Query возвращает нетипизированный список. Во многих проектах утилитарная функция его приведения — единственное место, где я реально использую cast.
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                        +2
                                                        У всех RoR-фагов одна отговорка «зато PHP еще хуже/тормознутее/тупее»… который от версии к версии становится все лучше, быстрее, функциональнее. Как по мне — Твиттер уже находится на том уровне развития, что может переписать ВСЕ на что-то мега быстрое. Например, на Erlang.
                                                          +2
                                                          Ну конечно… «неверный» откомментировал. Как он посмел упомянуть богомерзкий PHP в топике про православный Ruby. Ведь это же PHP стал быстрее, функциональнее и удобнее в последней версии. А Ruby — совсем наоборот. RoR фаги! Налетай меня минусовать!
                                                            +9
                                                            Ну а почему Вы лезите сюда с провокационными заявами — РОР кал — ПХП — чудо?
                                                            Здесь и так горюют рубисты, в том числе и я.

                                                            Дело не в том, что кто-то что-то переделывает во имя чего-то.
                                                            А как раз в том, что «кто-то что-то переделывает во имя чего-то.»
                                                            Улавливаете? Людям же насрать, что Твиттер в большинстве своем выстрелил благодаря Руби/рор.
                                                            Что развертка и масштабирование было в реалтайме. Что можно было диманически и довольно быстро учитывать пожелания клиентов/юзеров.
                                                            Людям настрать, что запросы к бд выросли с сотен до миллиардов обращений! У вас есть проект с такими запросами?
                                                            Людям насрать на то, что поддерживать рор проект намного лечге и экономически выгоднее, чем держать свору высококвалифицированных С/++ специалистов.

                                                            Люди слышат одно — Твиттер отказывается от Руби.
                                                            Значит Руби — кал! На кол его! Скала рулит! Хотя до этого момента абсолютное большинство даже и не догадывалась о существовании оного.

                                                            Да, обидно, чертовски обидно видеть как на ЯП сказывается политика одной, хотя и большой компании.

                                                            Но Мац далеко не дурак. Он увидел потолок. Предел. Что нужно оптимизация ради экономии.
                                                            Он уже над этим работает. (Я надеюсь..)
                                                            1.9 ветка была не об этом.
                                                            Кстати — твиттер страртовал еще на 1,8 руби со всеми вытекающими.
                                                            Если они до сих пор были на нем — это говорит об огромном потенциале.

                                                            Но люди же не слышат этого. ТВИТТЕР ОТКАЗЫВАЕТСЯ ОТ РУБИ! — вот всё, что на слуху.

                                                            А тут Вы еще со своим пхп.
                                                              +3
                                                              Люди видят то, что хотят видеть. Даже есть вы двести раз повторите в корне логичную и разумную мысль, человек все-равно преобразует ее в то, что его разуму более понятно.

                                                              Я к тому, что внимательные и грамотный читатель не видит в заголовке «Твиттер отказывается от Руби», этого и не подразумевается — Эван Уивер говорит о том, что Ruby (RoR) до сих пор остаются очень хороши для решения некоторых поставленных задач. Просто не всех.

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

                                                              Или вам неприятно видеть Ruby в качестве стартовой ступени разработчика?
                                                                +3
                                                                Мне? Да я уже год как не представляю иного ничего такого же быстрого и наименее затратного.
                                                                Руби в юниксе уже есть.
                                                                Всё, что нужно поставить -гемы или рвм. Далее рор.
                                                                Далее гитхаб.
                                                                Далее хероку.

                                                                И все это парой строкой в баше.
                                                                Это же прекрасно!

                                                                  0
                                                                  гит всё же, а не гитхаб? :-)
                                                                    0
                                                                    Да нет же.
                                                                    github.com через git, конечно же.
                                                                      0
                                                                      Обратно не понял. Установить гитхаб? У них исходники в открытом доступе? Да и зачем тебе гитхаб локальный? :-)
                                                                        0
                                                                        Ну да — залил исходники. Свои — им.
                                                                        Не хочешь светить — купи премиум — будет все в хайде.
                                                                        Итого — с любой точки у тебя доступ к своим проектам.
                                                                        А хероку подключил через гитхаб.
                                                                        Закомитил в гите, пушнул на хаб, обновил хероку — все. Все изменения уже в деплое.

                                                                        Или я чего-то не улавливаю в вопросе?
                                                                +1
                                                                Эм… Каким-таким функционалом обрастал Твиттер, что приходилось «диманически и довольно быстро учитывать пожелания клиентов/юзеров»?

                                                                Проблема была одна — тормоза и стабильность. Функционалам обрастала экосистема вокруг Твиттера, которую он потом начал скупать или имплементить самостоятельно — но уже в пост-RoRовские времена.
                                                                  0
                                                                  Пора и руби на себе испытать все то, что испытали на себе PHP и разработчики на оном… Никто не лучше и не хуже. Но когда кто-то теряет «канву», становится понятно, что такое истина… а истина в том, что теперь платформы Руби и ПХП схелестнутся на нейтральном поле… А значит — у нас, у олдскуллеров появилась надежда что «неофаги» схлопочут по самое небалуй от нас… Кто со мной… КТО СО МНОЙ, МОРПЕХИ!!!
                                                                    +1
                                                                    Как мне разпрочитать ваш комментарий обратно, я не хочу его знать?
                                                                  +3
                                                                  PHP стал быстрее, функциональнее и удобнее в последней версии
                                                                  Это как заявить «Лада стала быстрее/надежнее/удобнее» в топике о том, как како-нибудь олигарх пересел с Феррари на Майбах.
                                                                    –3
                                                                    Нет… это как «ламборгини (не феррари… в этом есть глубокий смысл) стала функциональнее и удобнее» в топике про то, что «строительная компания ИКС отказалась от техники Катерпиллер»… Вот что это…
                                                                      –1
                                                                      Ну не хотите «ламборгини», держите «ламборджини»… эстеты…
                                                                0
                                                                Поменяли один RunTime, на дргуой чуток побыстрее.

                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                Самое читаемое