Пользователь
0,0
рейтинг
14 марта 2013 в 18:51

Разработка → Как мы перешли с 30 серверов на 2: Go перевод

Как мы перешли с 30 серверов на 2: Go


Когда мы выпустили первую версию IronWorker около 3 лет назад, она была написана на Ruby, а API было написано на Rails. Через некоторое время нагрузка стала быстро расти и мы быстро достигли предела возможностей наших Ruby приложений. Короче говоря, мы перешли на Go. И если вы хотите узнать подробности — продолжайте читать…

Первая версия

Во-первых, немного истории: мы написали первую версию IronWorker, первоначально названную SimpleWorker (неплохое название, не так ли?) на Ruby. Мы были консалтинговой компанией, создающей приложения для других компаний, и в то время были 2 популярные вещи: Amazon Web Services и Ruby On Rails. И таким образом мы создавали приложения, используя Ruby on Rails и AWS, и привлекали новых клиентов. Причина по которой мы создали IronWorker была в том чтобы «почесать там где чешется». У нас было несколько клиентов, использующих устройства, которые постоянно отправляли данные в режиме 24/7 и нам приходилось эти данные принимать и преобразовывать во что-то полезное. Решалась эта задача путем запуска тяжелых процессов по расписанию, которые каждый час, каждый день и так далее обрабатывали данные. Мы решили создать что-то, что мы сможем использовать для всех наших клиентов, без необходимости постоянно поднимать и поддерживать отдельную инфраструктуру для каждого из них, чтобы обрабатывать его данные. Таким образом мы создали «обработчик как сервис», который мы сначала использовали для своих задач, а затем мы решили, что, возможно, кому то еще понадобится подобный сервис и мы сделали его публичным. Так и родился IronWorker.

Постоянная загрузка процессоров на наших серверах была около 50-60%. Когда нагрузка выросла, мы добавили еще серверов, чтобы сохранить загруженность процессоров примерно на уровне 50%. Это нас устраивало пока нас устраивала цена, которую мы платили за такое количество серверов. Большей проблемой было то, как мы справлялись со скачками нагрузки. Очередной скачок нагрузки (трафика) создавал эффект домино, который мог вывести из строя целый кластер. Во время такого скачка нагрузки, превышающей обычную всего на 50%, наши Rails-сервера начинали использовать процессор на 100% и переставали отвечать на запросы. Это заставляло балансировщик нагрузки думать, что этот сервер упал и перераспределять нагрузку между остальными серверами. И, так как, помимо обработки запросов упавшего сервера, оставшимся серверам приходилось еще обрабатывать пиковую нагрузку, то обычно проходило немного времени до падения следующего сервера, который опять исключался из пула балансировщика, и так далее. Довольно скоро все сервера приходили в нерабочее состояние Это явление также известно как colossal clusterf**k(+Blake Mizerany)



Единственный способ избежать этого с приложениями, которые у нас были на тот момент — использовать огромное количество дополнительных мощностей, чтобы снизить нагрузку на наши сервера и быть готовыми к пиковой нагрузке. Но это означало тратить огромное количество денег. Что-то надо было менять.

Мы переписали его

Мы решили переписать API. Это было простое решение, Честно говоря, наше API, написанное на Ruby on Rails, не было масштабируемым. Основываясь на многолетнем опыте разработки подобных вещей на Java, которые могли обрабатывать большую нагрузку используя куда меньшие ресурсы чем Ruby on Rails, я знал, что мы можем сделать это куда лучше. Таким образом, решение сводилось к тому, какой язык использовать.

Выбор языка

Я был открыт для новых идей, так как последнее, что я хотел сделать — это вернуться к Java. Java есть (был?) прекрасный язык, в котором много преимуществ, таких как производительность, но после написания кода на Ruby в течение нескольких лет, я был восхищен тем, как продуктивно я могу писать код. Ruby это удобный, понятный и простой язык

Мы посмотрели на другие скриптовые языки с лучшей производительностью, чем у Ruby (что было несложно), такие как Python и JavaScript/Node.js. Также мы рассмотрели базирующиеся на JVM — Scala и Clojure, и другие языки, как Erlang (который использует AWS) и Go (golang). Go победил. То, что конкуррентность была фундаментальной частью языка, было отлично; стандартная библиотека ядра содержала почти все что нам нужно было для построения API; он емкий; он быстро компилируется; программировать на Go просто приятно — так же, как и на Ruby, и, в конце концов, числа не лгут. После построения прототипа и тестирования производительности мы поняли, что можем без проблем обрабатывать большие нагрузки при помощи Go. И, после некоторых обсуждений с командой («Все в порядке, его поддерживает Google»), мы решили использовать Golang.

Когда мы впервые решили попробовать Go, это было рискованное решение. Не было большого коммьюнити, не было большого количества open source проектов, не было успешных случаев применения Go в продакшне. Также мы не были уверены, что мы сможем нанять талантливых программистов, если мы выберем Go. Но вскоре мы поняли, что мы сможем нанять лучших программистов именно потому, что мы выбрали Go. Мы были одной из первых компаний, которые публично заявили об использовании Go в продакшне, и первой компанией, которая разместила объявление о вакансии в рассылке golang. После этого лучшие разработчики захотели работать на нас, потому что они смогли бы использовать Go в работе.

После Go

После того как мы запустили версию на Go, мы снизили количество серверов до двух (второй нужен больше для надежности). Нагрузка на сервера стала минимальной, как будто ничего и не использовало ресурсов. Загрузка процессора составляла менее 5%, и приложение использовало несколько сотен КБ памяти (при запуске) в сравнении с Rails приложениями, которые отъедали ~ 50 МБ (при запуске). Сравните это с JVM! Прошло много времени. И с тех пор у нас больше никогда не было colossal clusterf**k.

Мы сильно выросли с тех времен. Сейчас у нас намного больше трафика, мы запустили дополнительные сервисы (IronMQ и IronCache), и сейчас мы используем сотни серверов, чтобы покрыть нужды клиентов. И весь бэкенд реализован на Go. В ретроспективе это было отличное решение — выбрать Go, поскольку это позволило нам построить отличные продукты, чтобы расти и масштабироваться, а также привлечь талантливых людей. И, я думаю, что сделанный выбор будет продолжать помогать нам расти в обозримом будущем.

PS Перевод сделан с разрешения Travis, и если возникнут какие либо вопросы, то он и другие члены команды Iron.io с удовольствием ответят на них.
Перевод: Travis Reeder
Роман Кононов @rkononov
карма
22,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (275)

  • +137
    «Все в порядке, его поддерживает Google», и Reader тоже поддерживала Google. Прошу прощения, не могу отойти от сегодняшнего.
    • +3
      Когда Google перестанет поддерживать Google Reader, тот просто перестанет работать.
      Если Google перестанет поддерживать Go, тот будет точно так же работать и дальше.
      • +31
        Вашими бы устами да мед пить. Кому нужна неподдерживаемая платформа?
        • +1
          ну исходники и вики переедут с googlecode на bitbucket, делов-то
          • +23
            А зачем? они могут продолжать гнить и на googlecode.
            • +58
              пока google и его не закроет.
              • +4
                Для гугла не будет большой проблемой к закрутию googlecode, еще бонусом прикупить bitbucket и закрыть его.
                • +1
                  Не думаю, что Atlassian продастся гуглю.
                  • +2
                    «Гугл купил Марсианскую программу… и закрыл как не популярную» :)
        • +1
          Платформа не прекратит существование в один день. Она будет работать и дальше. Ваши сервера не выключатся. Да, вам станет труднее найти новых специалистов для её поддержки в будущем. Но ваш бизнес будет работать, клиенты не убегут узнав, что Google прекратил поддержку Go.

          Или вам в одночасье станет противно работать с платформой, которая ещё вчера всем устраивала? :)
          • +15
            Конечно не убегут, им вообще наплевать на чем вы еще раз перепишете API.
      • +1
        И не будет развиваться, как, например, ReiserFS
    • +11
      Все в порядке, гугл поддерживает gwt. Подсадили пол мира на него и бросили.
      • +2
        Ну Go насколько я помню не так и сильно относится к Google, там основатели языка вроде работают, и на этом все. Вот Dart — это Google.
  • –24
    jruby не не слышали
    • 0
      Минуса за формулировку вполне оправданы, но мне тожe интересно, дал бы эффект переход на jruby.
      • 0
        Я бы хотел посмотреть сравнение скоорости, неужели python сильно медленнее Go, а comunity у него огромное.
        • +1
          Вы хотите сравнить скорость работы компилируемого и исполняемого языков? Сразу могу сказать, разница будет в 10-20 раз.
          • +2
            Нет никакого смысла сравнивать скорость работы кода. Нужно сравнивать скорость работы программ, выполняющих одинаковые задачи. Ну какой прок от того, что go быстрее складывает 2 числа, задача выбрать из базы данные и отдать их в json? И вот тут у go не все так радужно: стандартная библиотека довольно медленная.
            • 0
              Это уже частности, в разных языках есть разные косяки в библиотеках, можно для каждого языка подобрать неудачный пример. Последний раз когда я анализировал разные базы данных, у отдельных языков программирования был полный швах в скорости работы с МонгоДБ из-за библиотек. Но в целом компилируемые языки на порядок быстрее просто из-за своей природы.
              • +1
                > Это уже частности, в разных языках есть разные косяки в библиотеках
                Да, и именно это бывает важно для задачи.
                • 0
                  По вашей логике сравнить один язык с другим вообще оказывается невозможным, только в узких примерах, под конкретную уже поставленную задачу =)
          • 0
            Пруф?

            Разница не будет такой большой. Иногда вообще нет разницы. Иногда байткод быстрее (и теоретически и практически).

            Но вот в случае с языком Си можно добиться хорошего выигрыша в производительности, по сравнению динамическими языками, управляе выделением и освобождением памяти самостоятельно.
            • 0
              • 0
                Не касаясь остальной ветки, замечу, что в бенчмарках по ссылке стандартная ошибка при тестировании Java: отсутствие прогрева. Может, на тривиальном примере, как там, это бы и не сказалось, а на сравнении любых программ, состоящих более чем из одной функции, это сказывается.
              • 0
                Да, действительно в этом примере результат впечатляющий. Хотя сказалась опять же упревление памятью. Вынес декларацию переменных из цикла в Perl, время упало с 19 до 15 сек на моей машине.

                Вот пример работы со строками raid6.com.au/~onlyjob/posts/arena/ там вообще Perl обгоняет Си.
            • +1
              А за счёт чего байткод может быть быстрее?
              • 0
                В теории — например, если байткод вместе с его интерпретатором лучше влезают в кэш процессора, чем нативный код.

                На практике — есть JIT, он сможет скомпилировать часто используемый кусок байткода в нативный, с нужными оптимизациями (он будет знать какая ветвь там чаще выполняется).

                Или может дело в библиотеках. Например в Perl — массив имеет некоторое количество памяти выделенное до него и после него, поэтому нормально (быстро) работает как стэк или очередь. Так что если взять и написать «простую» программу где используются обычне массивы без всяких библиотек, то Сишный массив может проиграть.

                А если в Си постоянно использовать библиотеку с самыми умными массивами которые только может быть, Си потеряет преимущество контроля за выделением/освобождением памяти (очень медленная операция по сравнению с арифметикой).

                вот в примере raid6.com.au/~onlyjob/posts/arena/ показано что Перл быстрее Си в операциях со строками.
    • 0
      Кстати, нет… правда не слышали…
  • +13
    Кто-то может объяснить, что случилось с руби? Вроде ещё недавно холивары были что лучше руби vs python, если совался с php, то заклевывали моментально.

    Сейчас такое ощущение, что со всех сторон плевки на руби идут. Что произошло?
    • +74
      Мода прошла
      • +4
        Ага. Люди поняли, что писать сайтики для двух людей на руби прикольно, а вот высоконагружённые приложения — совсем не айс. И он годится только потешить своё удовольствие.
        • –3
          Совершенно не согласен.

          С Ruby и Ruby on Rails все как раз айс и даже больше!
          Руби набирает все большую популярность и постоянно развивается в лучшую сторону.
          Сам пишу на RoR и каких-либо тормозов не замечаю.

          «Сейчас такое ощущение, что со всех сторон плевки на руби идут. Что произошло? » — не то и не там читаете, вот что произошло. Я не видел вообще никакого негатива в сторону Ruby.

          Вполне возможно, что идолопоклонники приверженцы php вряд ли могут вам сказать что-то хорошее о Ruby, оно и понятно — Ruby давно уже заткнул за пояс php по производительности, а это был наверное единственный аргумент в пользу php когда-то.
          • +1
            Ruby давно уже заткнул за пояс php по производительности

            benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=yarv&lang2=php
              • 0
                Что сказать-то хочешь?
                • –2
                  хотя бы то, что тесты должны быть абсолютно идентичными в коде, это во-первых
                  во-вторых — если даже на простейших тестах видна такая значительная разница, я не думаю, что на более сложных тестах что-то должно кардинально измениться.
                  хотя да, согласен, нужно будет написать еще пару-тройку тестов — структуры (деревья, списки), массивы, строки, регулярки — чтобы уж точно было более убедительно
                  • +4
                    > тесты должны быть абсолютно идентичными в коде
                    Тесты должны использовать все преимущества языка.
                    • 0
                      назовите мне хоть одно преимущество php, по которому он будет проходить тест быстрее других языков программирования?
                      именно поэтому я и написал тесты, которые повторяют код друг друга в точности, но на разных языках
                    • +1
                      преимущества, говорите?

                      вот специально сейчас глянул на исходники тестов на benchmarksgame.alioth.debian.org и сравнил…

                      совершенно странно, почему обычные циклы в php сравниваются с итераторами в Ruby? Итераторы — это более медленный механизм, хотя и более мощный несомненно. Давайте тогда уж будем до конца честными — заменим все итераторы в коде теста Ruby на обычные циклы и тогда уж сравним.
                      • 0
                        Замените. Насколько я знаю, патчи приветствуются.
                        • –2
                          Оно мне надо?
                          Мне достаточно собственной уверенности, а остальным стоит задуматься — а всему ли надо так безоговорочно верить? Зачастую не лишне и перепроверять.
                          • +8
                            Ну гундеть и порть горячку вам надо, а поправить не надо. Вот так и живем.
                            • –1
                              Стандартный ответ: «Сам дурак!», когда нечего уже возразить, остались лишь эмоции и слюни. Знакомо ;-) Не утруждайтесь в оскорблениях — все-равно мимо.

                              Просто я всегда пытаюсь разобраться, а не просто верить всему на слово.
                              • +1
                                Просто я всегда пытаюсь разобраться, а не просто верить всему на слово.


                                Пока что ваша теория подкреплена только вашими словами и больше ни чем. Так что, большинство поверить тем тестам, а не вам. Хотя возможно вы и правы.
                                • –1
                                  Я не собираюсь разбиться об стену, только лишь кому-то доказать свою правоту. Дело каждого — кому и во что верить.

                                  Но, следуя хотя бы простейшей логике, если даже в простейших алгоритмах есть пройгрыш в производительности, то с какого перепугу вдруг должно произойти обратное на более сложных? Если размышлять здраво — любой сложный алгоритм — это совокупность более простых.

                                  Моя теория подкреплена абсолютно идентичным кодом на разных языках программирования, в отличии от абсолютно различной реализации алгоритмов тестов на benchmarksgame.alioth.debian.org. Зачем вводить в заблуждение? Там более, что такой (вроде как) авторитетный источник.
                            • +2
                              Вы сами патчи туда присылали? Подтверждаю что это не правильные бенчмарки (по собственному опыту) +
                              habrahabr.ru/post/119579/
                              • 0
                                Во!.. «А мужики-то не знают...» ;-)
                        • –1
                          Да сами проведите замеры и представьте публике, если лень патчи делать.
                          • +1
                            Вот, не поленился. Спасибо доброму человеку — предоставил код теста mandelbrot.

                            Сравнение производительности Ruby и PHP.

                            Не стоит все же всему безоговорочно доверять.
                            • 0
                              Мне казалось, в Руби jit. И всего 20%?
                              • 0
                                Вам именно казалось, а желательно все-таки знать.
                                А 20% на таком тесе — это очень даже не мало.
                                • 0
                                  Действительно, не могу найти точного указания на этот факт, хотя есть много упоминаний вскользь (хотя бы вот). Значит на самом деле там нет jit?
                              • 0
                                В тестах, где производится вызов метода объекта, пройгрыш PHP составляет около 50%, что фактически в 2 раза медленнее, чем Ruby.
                                Еще какие-то вопросы есть?
                              • +1
                                Напомню, что реализаций ruby несколько.

                                MRI — JIT'а нет, его пока пытаются пилить.

                                JRuby — JIT самой JVM, сам JRuby пытается оптимизировать довольно много, чтобы позволить лучше работать JIT'у JVM. Дополнительно можно посмотреть здесь: github.com/jruby/jruby/wiki/JRubyInternalDesign.

                                Rubinius и MacRuby — имеют свой JIT.

                                IronRuby и Ruby.NET — используют JIT .NET CLR, насколько понимаю.
                                • 0
                                  Я имел в виду ту реализацию, которую использовал Sega100500, MRI.
                                • –1
                                  Спасибо за напоминание, Капитан Очевидность!

                                  Если бы я имел ввиду какую-то иную реализацию, я бы так и написал, тем более, что у них у всех различные названия, не так ли?

                            • 0
                              Поскольку сам пишу на node.js, решил проверить, как дела в нём:

                              gist.github.com/AlexeyKupershtokh/5180271
                              • –3
                                совсем некорректное сравнение, мне кажется
                                в JS используется JIT — конкретно в NodeJS — V8
                                я не специалист в NodeJS, поэтому эти выводы только с помощью гугл сделал
                                • +1
                                  > совсем некорректное сравнение, мне кажется
                                  лол
                                  > тесты должны быть абсолютно идентичными в коде
                                  • –2
                                    да, но на подобных друг другу языках…
                                    вы не путайте, пожалуйста
                                    проще можно было бы тогда сравнить PHP и C
                                    • +1
                                      да, но на подобных друг другу языках…
                                      проще можно было бы тогда сравнить PHP и C
                                      Поскольку сам пишу на node.js
                                      • –1
                                        Писали бы Вы на C, все вообще бы в шоке были, насколько тормоза эти PHP/Ruby/Python ;-) )))
                              • –2
                                для примера, небольшое добавление простейшего динамизма в код JS:

                                var $test = 'abcde';



                                и внутри цикла:

                                var $tr = $zrzr — $zizi + $cr;
                                var $ti = 2.0 * $zr * $zi + $ci;

                                $test = $test[3] + $test[0] + $test[4] + $test[1] + $test[2];

                                тут же увеличивает время выполнения кода JS на порядок (в 10 раз)!

                                для примера, время выполнения идентичного кода на Ruby увеличилось в 6 раз.
                                • 0
                                  тут же увеличивает время выполнения кода JS на порядок (в 10 раз)!
                                  То, что нода с палками в колёсах все равно ездит в 3 раза быстрее ruby и php, как-то должно меня от нее отпугнуть? :)
                                  • 0
                                    Конечно же нет!
                                    Вообще выбор ЯП — дело сугубо каждого.

                                    Разве я собирался кого-то пугать? Вообще не агитирую за смену ЯП или системы разработки. Каждому — свое! К слову, JS мне вообще не нравится, я могу его терпеть только в виде JQuery максимум.

                                    В начале я вообще привел сравнение 2-х (истинно) скриптовых ЯП, не предполагал, что это вот в такую ветку обсуждений растянется, да еще и придется дополнительные эксперименты проводить.

                                    Но вывод я сделал — на хабре всем троллям не угодишь, которые норовят шмякнуть минус и вякнуть что-то.

                                    Побольше бы таких, как вы — которые хотя бы реальные эксперименты проводят, чтобы убедиться в чем-то.
                                  • –1
                                    так, для общего развития… на простейших тестах JS проигрывает по производительности Ruby в 6-8 раз… проверил только на 1-ом тесте.
                                    И, кстати, в фреймворках как раз достаточно интенсивно используются вызовы методов объектов и функций.

                                    Все по-честному, без обмана у Волшебника Сулеймана — никаких «с палками в колёсах».

                                    Но это ни в коем случае не должно Вас отпугнуть от использования NodeJS. Боже упаси!

                                    Это просто я все пытаюсь провести разностороннее тестирование.
                                  • 0
                                    … хотя не везде так. В разных браузерах совершенно разная скорость. NodeJS не установлен, поэтому скорость проверяю в браузерах FireFox, Opera, Chrome.
                                  • 0
                                    провел еще несколько тестов…
                                    нет, все же Javascript с V8 быстрее (что нисколько не удивляет, если верить Википедии: «Компиляция исходного кода JavaScript непосредственно в собственный машинный код, минуя стадию промежуточного байт-кода.».

                                    Но самое интересное в том, что в Ruby запросто можно использовать этот движок V8, т.е. какие-то особо критичные до скорости алгоритмы можно запросто реализовать на нем, оптимизировать. Тест вычисления Фибоначчи с использованием V8 выполняется примерно в 7 раз быстрее. Такие вот дела.
                                    • 0
                                      1) Вы недавно говорили, что сравнивать компилируемые языки с некомпилируемыми, а теперь сравниваете.
                                      2) Вы недавно говорили, что вам JS не нравится, а вот вы уже готовы писать на нём, да еще и без JQuery. Не говоря уже о том, что это будет внутри руби, что имхо еще хуже, чем писать на чистом языке.
                                      • –3
                                        1. Такой уж пытливый ум у меня — попытался выяснить причину этого превосходства. Всегда считал JavaScript скриптовым, а он вон как — перекочевал с помощью V8 практически в нишу компилируемых языков. Все потому, что никогда особо не интересовался JS, и не собираюсь в дальнейшем.

                                        2. Не только говорил, но и говорю — не нравится мне JS, и воспринимаю его максимум в виде JQuery. На нем писать не собираюсь, не более того, чем это нужно будет в веб-приложении — всегда хватает небольших JS-вставок. Просто нашел способ оптимизации «узких мест» в программе на Ruby. Совершенно даже не призываю использовать это, просто такой способ есть — как факт.

                                        Меня Руби устраивает во всем и полностью.
                      • +2
                        Плюсую. benchmarksgame.alioth.debian.org — это не бенчмарк.

                        Это бенчмарк * соревнование программистов что в итоге переодически даёт 0.

                        Видел как сравнивается одно выражение на ruby с циклом на perl, что явно фейк. Так же много где не удалось увидеть исходник (сайт глючил).

                        И судя по отзывам автор не очень дружелюбен, и в место того чтобы обеспечить честность бенчмарков говорит «присылайте патчи» и сам их отвергает если они лично ему не нравятся.
                        • 0
                          Вообще сама идея делать такой сайт… Это всё равно что написать критичеси важную программу на 10 языках одновременно, которых сам не знаешь.

                          В случае критического бага отвечать «пришлите патч, сделайте форк» и ничего самому не делать.

                          Весь такой «продукт» можно отправлять в корзину, поэтому и патчи туда присылать даже не хочется.
          • +3
            Синтетические тесты — ничто. Не устану этого повторять. Пиши код на том, что знаешь.
            • 0
              Я знаю и php, и Ruby, но вот на php возвращаться уже нет совершенно никакого желания. Единственное, что меня сейчас связывает с php — это предыдущие разработки, которые так или иначе надо совершенствовать… пока не найду время все это переписать на Ruby.
              • +1
                У рубистов столько времени на холивары, а на то, чтобы напрочь забыть php и «переписать все это» на руби, времени нет… Зачем разводить бессмысленные языковые войны и поддерживать извечное противостояние «такого плохого» php и «такого замечательного, чмок-чмок-чмок его во все места» руби в посте… про go.
                • –2
                  Я не сказал, что php — плох. Просто желания уже возвращаться к нему нет, пройденный этап.
                  Php вполне себе приличный язык. Про php я вообще упомянул вскольз.

                  Но то, что надо бы переписать во-первых слишком объемное, а во-вторых — текущих проектов на Руби достаточно для того, чтобы не было времени отвлекаться на что-то еще.
                  • +1
                    На что-то еще кроме холиваров, видимо…
                    • 0
                      Холивар я не собирался разводить, честное слово!
                      Как говорится, это Вы меня неправильно поняли ;-)

                      На самом деле работы предостаточно!
      • –1
        да-да, просто кто-то из разряда «ниасилил» сказал, что это уже не модно и двинул туда, где попроще ;-)
        • –3
          Куда уж проще Руби?
        • +1
          Лично я ничего плохого к руби не испытываю, стараясь во всем найти здравый смысл. И вместо обсуждения языков, хотел бы заметить, что рубисты все чаще стали напоминать мне… знаете, есть такие владельцы айфонов, которые уже на том основании, что у них «телефончик с яблочком» считают себя людьми высшего сорта.

          Руби — круто. Рубизм головного мозга — очень плохо.

          И вообще — на мед слетается мух столько же, сколько на навоз… но только это мухи разного вида.
          • –1
            Решаюсь улететь в минуса, но все же продолжу Вашу гениальную мысль…

            А PHP-изм головного мозга — это…

            варианты ответов не предлагаю.

            Согласитесь, сколько холивара было начато именно на почве PHP.
            • +3
              Я вообще сейчас улечу в минуса. Я считаю, что сравнивать языки надо не с позиции «быстро/медленно» или «модно/не модно», а с позиции выгоды. То есть, надо трезво оценивать — сколько может принести использование каждого конкретного языка за единицу времени. Тогда и с холиварами проблем не будет — эти цифры будут сугубо индивидуальными.
              • 0
                Лично мой опыт, только мой — на написание сайта средней сложности на php у меня уходило 1.5 — 2 недели, на Ruby — 1 — 1.5.
                И кода значительно меньше получается.
                • 0
                  А еще я бы хотел заметить, что то, что выгодно фрилансеру не всегда выгодно заказчику… даже если предположить, что обе стороны стремятся реализовать проект наилучшейшим образом. Безотносительно языков или платформ.
                  • –4
                    1. Я не фрилансер
                    2. Я всегда стараюсь выполнить именно пожелания заказчика, потому как продукт пишется именно для него. Конечно, исключая случаи, когда требуется реализовать уж какой-то совершенно бред.
                    3. Преимущества сайта на Ruby, я думаю, будут очевидны даже заказчику.

                    Для заказчика прежде всего важны: соответствие проекта его пожеланиям, скорость исполнения проекта, надежность его работы, мне так кажется. А вот исполнителю как раз важно показать, что он сможет все это реализовать с помощью того инструмента, которым пользуется — в данном случае — система разработки, выбранная для реализации проекта. И желательно, чтобы потом не пришлось переписывать все на Go ;-)
                    • 0
                      Кроме перечисленного для заказчика важна также легкость дальнейшей поддержки и быстрая замена в случае чего одного разработчика на другого. Найти хорошего пхп-программера, имхо проще чем просто рубиста.

                      Но тут не только пхп, есть ещё питон, который как мне кажется более популярен чем руби с рельсами, но имеет те же преимущества.
                      • 0
                        Хороших разработчиков примерно везде одинаково, независимо от языка программирования. Тем более, тенденция последнего времени такова, что очень часто, начав с php, разработчики предпочитают сменить язык на Python или Ruby.
                        • +1
                          >Хороших разработчиков примерно везде одинаково, независимо от языка программирования.

                          То есть, на брейнфаке хороших программистов тоже самое количество, что и например, на сях?
                          • 0
                            Да, примерно одинаково. Именно хороших, а не всяких. И, как правило, первоклассные специалисты владеют несколькими языками программирования.
                            Я знаю (и имею опыт разработки) на Assembler, Pascal, C, C++, Delphi, C++ Builder, но для веб выбрал сначала Perl, потом PHP, сейчас Ruby.
                            И хочу сказать, что Ruby тем и хорош (ко всему прочему), что если заказчик нашел программиста на Ruby, то он с бОльшей уверенностью может предполагать, что это программист по крайней мере среднего уровня.
                            Это не голословные утверждения — мне доводилось сталкиваться с тем «кодом», который написал один деятель, закончивший 3-месячные курсы по PHP и считавший себя программистом. Контора до сих пор разгребает то дерьмо, что он понаписал. А я им сразу сказал, что в этом навозе я ковыряться не собираюсь — я не сантехник, мне гораздо проще было взять и написать все заново.
                            • 0
                              .
    • +24
      А откуда ещё плевки? Если можете, покидайте ссылочек.

      А по теме, то кажется, всё в порядке: ребята быстро написали продукт на Rails, пришла пора масштабироваться — выбрали более подходящее решение.

      Во-первых, не факт, что они не могли всё оптимально переписать на Ruby (например, используя другой фреймворк, активнее используя кеширование, переработав логику и т.п.). Во-вторых, даже, если и не могли, то, кажется, ничего страшного. У каждого языка\фреймворка должна быть своя ниша. Судя по тому, что их сервера перестали справляться Ruby\Rails прекрасно выполнили свою функцию.
      • +36
        Судя по тому, что их сервера перестали справляться Ruby\Rails прекрасно выполнили свою функцию.

        Хорошо сказано :)
      • 0
        Я не рубист, поэтому особо не запоминаю ссылки. Но как-то из обсуждений, комментариев и и.т.д сложилось такое впечатление.
        • +2
          Очень много, порой, обсуждают и комментируют (негативно) как раз те, кто вообще мало представления имеет о Ruby — чаще всего это какое-то абстрактное мычание, совершенно не подкрепленное практическим опытом.
    • 0
      Сейчас все больше склоняются к тому, что Ruby и Ruby on rails больше подходят для быстрой разработки прототипа. Написали, выкатили потестировали, переписали, потестировали и т.д. На больших нагрузках, как правило выбирают другое решение, либо комбинируют…
      • +4
        Так и есть.

        Быстро написали — быстро выкатили — получили Proof of Concept — быстро нарастили клиентскую базу — у вас завелись деньги — нанимаете толпу инженеров и меняете платформу на более серьезную, если простая оптимизация узких мест не спасает.
      • –1
        гугол вот уже.давно использует питон для быстрого прототипирования, потом все на яву перегоняют.
    • +3
      Это совершенно не плевки в сторону Ruby. Ребята быстро написали прототип, выкатили в production, подняли на этом деньги и переписали сервис на инструменте, который к конкретно их задаче подходит лучше.

      Ruby или Rails сами по себе не плохи, и там где надо, они справляются лучше всех. Но если какая-то компания отказалась от Rails в сторону чего-то быстрого, вероятно они просто адекватно оценивают задачи и подбирают инструменты. Не более, не менее.
    • +1
      Ничего не случилось. Автор не говорит про ruby, он говорит про рельсы. А рельсы пишуться с идей «перформанс оставляем на потом, сейчас главное, чтобы всё было красиво».
  • +27
    We decided to rewrite the API. This was an easy decision

    Мы решили переписать API. Это было непростое решение

    • +3
      спасибо, поправил, скорее всего Travis опечатался, решение насколько я помню было не простое )
  • +4
    Было бы интересно узнать подробнее — как выбирали язык. Интересно, почему отказались от erlang
    • +1
      Это же перевод.
      • +2
        тем не менее ответить на вопросы мы можем :)
        PS думаю через пару часов, когда проснутся
    • +1
      Могу предположить, что переписывать с Ruby на Go всё-же проще, чем на Erlang. Проще в смысле проще переносить код 1 в 1. На Erlang/OTP придётся существенно перерабатывать.
      • 0
        Нынче уже есть elixir-lang.org/
      • 0
        перенос кода 1 в 1

        Предположу существование еще одного важного фактора, действующего против Erlang — это отсутствие встроенных в язык словарей (aka dict, HashMap, map)
        • +2
          Я для маленьких использую orddict:, для покрупнее dict:. Если нужен O(1) доступ — можно ETS использовать. Возможно, конечно, есть проблема что они не встроены в язык, но как-то обходимся.
  • +9
    Производительность 1 к 32, это чего это Ruby такой медленный то и в Ruby ли дело?
    • +9
      Ruby достаточно быстр, дело больше в Rails – его разработчики никогда не чесались о производительности. Плюс если IronWorker спасла конкуррентность — скорее всего производительность упёрлась в GIL
      • 0
        GIL, как мне кажется, вообще всю идею конкурентности на корню убивает. Тогда уж проще на процессы разбивать все и не использовать нити вовсе.
        • 0
          Ну, т.е. они упёрлись в стенку так как concurrency в ruby и не пахло
          • 0
            wut? Fibers — самые что ни на есть корутины.
            • 0
              И что? Корутины != конкарренси
              • 0
                Через корутины реализуется конкурентное программирование.
        • +1
          а при чем здесь GIL и конкуренция?
          concurrency != threads
      • 0
        Где там сказано что у них был один процесс? Не ужели бы они не заметили что только одно ядро используется?
        • 0
          GIL не позволяет потокам работать на разных ядрах, поэтому профиты от многопоточности сводятся почти к нулю. Из за GIL такие языки, как Ruby, Python, PHP, никогда не будут быстро работать в случае многопоточного программирования. Это ограничение by design, нужно или на процессы переходить, или на другие языки программирования.
          • +1
            В языке Python архитектурно нет никакого GIL, он есть в реализации CPython. В IronPython глобальных блокировок нет (мелкомягкие его поматросили и бросили, но он всё ещё рабочий). В Jython тоже такого анахронизма нет.

            Подозреваю, аналогичная история с Ruby — не все реализации одинаково полезны.
            • +2
              Да, в Ruby, как я помню, только в MRI (референсная реализация) есть GIL. А jruby, rubinius — без GIL.
          • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Большое спасибо за расказ о GIL.
            Я как раз про то и говорю, что у них явно был не один процесс, а много. Соответсвенно GIL тут не причём.
          • +1
            В JRuby есть честные потоки, а в офф интерпретаторе уже ввели или почти ввели.
    • +2
      Думаю дело в тяжеловестности/оверхеде Rails и всяких других гемов.
      • –1
        Думаю дело вот в этой шляпе.
        habrahabr.ru/post/84629/
        • +5
          Т.е. Вы хотите сказать, что серьёзные, взрослые люди, запустили один процесс, на сервере, посокрушались что он занимает аж целых 50 мегабайтов памяти, посмотрели что он занимает одно ядро максимум, и решили переписать всё на Go, на узнав что такое GIL?
  • +109
    Смешная история. Если отбросить мусор, звучит она примерно так:

    Мы решили сделать сервис под себя для агрегации данных.
    В то время хиповыми трендами были Amazon-овские облака и Ruby, и мы выбрали их, потому что в Java нам обои надоели, а инструменты под задачу мы выбираем по принципу «это модно».
    Когда сервис заработал, выяснилось, что производительность Ruby вообще никакая, хуже чем даже JS, сервера у Амазона очень дорогие, а архитектура нашего балансира нагрузки такова, что при первом же пике у него случается каскадный отказ серверов (это вообще шикарно!). Поскольку наш код конечно же был очень качественным, то мы решили, что во всем виноват Ruby!
    Тогда мы решили подвигать кровати и сменить язык программирования, на ещё более экзотический GO.
    Сначала мы боялись, что не сможем нанять крутых спецов по нему, но потому выяснилось, что даже крутые спецы по нему сидят без работы и прибежали к нам по первому зову. Среди них нашлись нормальные программеры, которые исправили нашу кривую архитектуру, и оказалось, что под нашу задачу с головой хватает 2 серверов. Вот такой волшенбый GO!

    Короче, как в анекдоте. Ребята при составлении т.з. оперируют понятием «модные технологии» и думают, что отравились овсяным печеньем.
    • +1
      Справедливости ради речь шла о недостатках масштабируемости RoR, а не Ruby, и выбирали скриптовый язык (для задач iron.io, наверное, имеет смысл). Хотя, конечно, дело навряд ли было в переходе на Go.
    • –1
      модные технологии это достаточно важный критерий, для некоторых, хотя я тоже с ним не согласен
      • –21
        По правде говоря, производительность кода зависит в первую очередь от компилятора, потом от программиста потом от железа!!!
        Если железо не тянет меняем железо, если код тормознутый меняем код, если код не тянет меняем компилятор.
        Только вот жаль что еще нету одного пункта «Поменять МОЗГИ»

        Может быть они имели виду что GO создавался компанией ГУГЛ как раз для больших нагрузок ??
        Ведь не секрет что сервера гугл тоже падают!!!
        • +18
          Как вы тут оказались, если не секрет?
        • +7
          По правде говоря, производительность кода зависит в первую очередь от компилятора, потом от программиста потом от железа!!!

          В теме элитный специалист в области компиляторостроения, все в виртуальную машину! Его компиляторы настолько интеллектуальны, что даже bubble sort компилируют в набор инструкций работающий за n*log(n).

          А программисты не нужны, вот.
          • 0
            bubble sort? не, не слышал. Есть же mySuperArray.sort(), нету никакого метода bubble_sort…
            кхм, простите, это я к тому, что интерпретируемые языки обычно способствуют не думать о сложности алгоритмов, может автор это имел ввиду. Хотя кто ж его знает :)
      • +6
        > Мы были консалтинговой компанией, создающей приложения для других компаний, и в то время были 2 популярные вещи: Amazon Web Services и Ruby On Rails. И таким образом мы создавали приложения, используя Ruby on Rails и AWS

        Для консалтинговой компании более чем нормально использовать то, что модно — ведь частенько со стороны заказчиков использование модных и известных технологий заявляется как необходимое условие. Т.е. в данном случае компания умело использовала тренды.
    • +3
      Спасибо комрад, вы написали то что я хотел. У меня вообще всегда ощущение от таких вот кейсов (уже второй на моей памяти) очень печальное.
      Я CTO и я выбираю технологии исключительно с подхода моды. Я сделал первую версию весьма плохой. Но не могу же я признать, что взял совершенно не верные инструменты в виде rails? Может быть мне стоит не тратить деньги фирмы. не выбрасывать наработки и опыт людей? может стоит оставить все на руби, но переписать на EventMachine или fibers. Может хотя бы провести тесты..? эмммм, неееет, лучше перепишем все на новом модном языке. И чудо, чудо правильно выбраная парадигма жрет разумное количество ресурсов. Стоит ли теперь признать, что я некомпетентен? эммм, неее, лучше обвиню неверно мной выбранный инструмент.

      В прошлый раз, тоже ктото из Linked рассказывал, как он заменили синхронный rails на асинхронный node.js для чата (или чего то подобного) и тоже как дети радовались что заработало быстрее.

      Ну тут же все взрослые люди, прирост производительности в 15 раз, только за счет языка? верится с трудом. Сложно судить не зная задачи, но почти уверен, что перепиши они задачу на fibers, нууу 4 бы сервера использовали. Зато сколько денег на разработке бы сэкономили.
      • 0
        С другой стороны веб-приложения с претензией на динамичное развитие написанные на Java доставляют. Правда проблем разработчикам, которые не успевают угнаться за рынком.
      • 0
        Почему Вы решили что дело в модели многопоточности? Да ruby код не в вакуме живёт. Использует библиотеки, гемы, решающие всякие практические задачи, которые тоже могу влиять на производительность.
        • 0
          Основная проблема, что статья скорее вброс чем источник информации. Любой компетентный человек сделал бы две вещи:
          1)Хотя бы _попробовал_ бы пофиксить архитектуру на текущей платформе. Ну чисто изза экономических соображений.
          2) Произвел бы хотя бы минимальные бенчмарки на каком то подмножестве своей задачи и получил бы конкретные _цифры_

          Оперирование фактами и цифрами, вот что отличает компетентного инжинера, от фанбоев. Если автор не приводит все эти «несущественные детали», то конечно можно предполагать что он все это делал… но известная бритва требует признать, что скорее все намного проще и это просто не делалось.

          В целом, следуя собственной логике, я считаю обсуждать тут нечего — ни фактов, не цифр в статье нет. Как оно там было на самом деле, можно только предполагать.
      • +2
        Вообще-то, производительность легко может вырости в несколько раз только за счет использования другого компилятора. Например, по этой ссылке в последней таблице некоторые программы, скомпилированные Intel C++ Compiler, в 3 раза быстрее, чем скомпилированные GCC (да, это не 15 раз, но тем не менее).
        • +4
          Да как же с этим поспоришь, от оптимизатора много зависти. Я понимаю разницу между интерпретируем Ruby и компилируемым go. И собственно на счет скорости ruby иллюзий в принципе не имею. :)
          Но уважаемые комрады… увеличение производительности в 30 раз (он пишет что второй сервер для резерва и в комменте выше я это не учел) просто за счет смены языка. Я верю в это с трудом. Скорее всего все же были и какие то архитектурные изменения которые позволили такого добиться.
          • 0
            В go нет особо развесистых фреймворков, в которых чтобы добраться до целевой части нужно выполнить тыщу и одно действие. Плюс, все что нужно можно пустить асинхронно через go. Так что не чего там удивительного нет. Менять скорей пришлось не архитектуру, а структуру кода, что как бы и так понятно…
            • +2
              Ну а в rails к руби гвоздями что ли прибит? Что мешало убрать его. Легковесных фремворков в руби достаточно. Включая асинхронные.
              И вынужден с вами не согласится — переход на асинхронную парадигму, это архитектурное решение. Иначе вообще любые изменения в приложение, можно было описать как «изменение структуры кода». Что в целом конечно правда, но слишком широкое определение что бы было полезным.
              мое имхо, что статья должна называться «как мы переписали код используя асинхронный подход (ну и кстати перешли на go) и уменьшили потребляемые ресурсы».
          • 0
            Как-то раз (для выбора на чем писать) на Python 2.7 измерял скорость цикла с небольшими арифметическими выражениями (сложение, умножение, деление). Потом сделал тот же цикл на делфи. Скорость была почти в 100 раз больше. Далее сделал библиотеку с этим же циклом на Cython'е и вызывал функцию из питоновского скрипта. Таким образом увеличил скорость выполнения скрипта в 20 раз. А Вы говорите в 30 раз не может…
            • +1
              Веб-сервера редко занимаются арифметикой. А скорость работы с текстом (http, html, json) отличается уже не так сильно и узкие места в основном вынесены в оптимизированные модули.
        • +1
          Это синтетические числодробильные тесты. В реальной жизни всё упирается в работу с БД или в работу с памятью.
      • +4
        Ну тут же все взрослые люди, прирост производительности в 15 раз, только за счет языка? верится с трудом.

        Очень даже может быть, однако go как раз-таки и создавался для написания сильно нагруженных веб-сервисов.
        И то, что ruby — это «вечный тормоз прогресса», тоже ни для кого не секрет, интерпретируемый язык с динамической типизацией. Тогда как go — компилируемый язык со статической типизацией. Поправьте меня, если я не прав. Вот если бы увидеть реальный бенчмарк сравнения двух языков, тогда было бы о чем говорить, а так — сплошные догадки.
        • +1
          поправляю: со строгой динамической типизацией

          • –1
            У Go — статическая типизация. Программы на этом языке получаются очень шустрыми, такой язык, как Ruby, легко может слить Go по скорости в 10 и более раз. Советую всем (программистам, которых интересует данная тема) прочитать откровения Роба Пайка от том, как, для чего, и каким образом создавался этот язык и его компилятор. Многие вопросы отпадут.

            p.s.: здесь неплохо написано про Go: хабрастатья
            • +1
              очень хотелось бы увидеть пример кода с 10-кратным превосходством производительности, очень!
        • +1
          В статье, как раз, речь идет именно о «реальном бенчмарке». Нет?
          • 0
            В статье речь о том, как один серьезный большой проект переписали на другом языке (другие люди). То есть функционал остался тот же, а начиника изменилась. Таким образом, здесь значительную роль сыграл динамический фактор. В моем понимании бенчмарк — это несколько другое.
            • 0
              не динамический фактор, а человеческий :)
            • 0
              На всех не угодишь. Напишут бенчмарк — скажут, что это синтетические тесты, вот если бы на боевом сервере — тогда б да. Напишут success story про успешный опыт оптимизации сменой тормозной платформы на менее тормозную — скажут подавай бенчмарки ибо у авторов success story руки кривые.

              Я не про вас — я про общий настрой комментариев в этом посте.
              • +2
                Ну дык и бенчмарк и саксес стори показывают тормознутось Руби, имхо)
        • –2
          у руби ведь есть jit тоже…
    • +10
      Хорошо передёргиваете, с огоньком.
      в Java нам обои надоели
      «Java is (was?) a great language» не значит, что «Java превосходна» — это значит «не будем заострять внимание на недостатках Java, чтобы не провоцировать оффтопичный срач»
      инструменты под задачу мы выбираем по принципу «это модно»
      ведь не может же быть, чтобы эти тупыепиндосы исходили из скорости разработки или вообще каких бы то ни было рациональных соображений.
    • 0
      Скролил вниз в поисках такого камента. Сам руби разработчик, но для агрегации данных никогда бы не вырал руби.
    • 0
      Спасибо, Вы очень подняли мне настроение с утра своим комментарием! :)
    • +2
      Я конечно понимаю что целью было максимальное передергивание и гипербола, но все же
      Сначала мы боялись, что не сможем нанять крутых спецов по нему, но потому выяснилось, что даже крутые спецы по нему сидят без работы и прибежали к нам по первому зову.

      Вы правда думаете что есть крутые спецы, которые знают Go и только его?
      Вы правда думаете что перспектива работать (а не только писать для себя) на языке, который тебе больше по душе — это не аргумент?
      Короче, как в анекдоте. Ребята при составлении т.з. оперируют понятием «модные технологии» и думают, что отравились овсяным печеньем.

      У ребят все отлично :) Они написали штуку на RoR, которая быстро стала популярной, появилась проблема с производительностью, переписали (язык имхо вообще не ключевой фактор, хотя Go в их случае — хороший выбор), тем самым избавились от проблемы. Классика.
    • 0
      отлично сформулировано! меняем в статье GO на Scala, Clojure или Erlang и смысловая нагрузка не изменится. Абсолютно анекдотичные выводы
  • +12
    может Ruby и не самый быстрый, но при определённой правильности рук легко можно добится хороших результатов.

    с масштабируемостью тоже всё в порядке — habrahabr.ru/post/170033/

    просто надо выбирать инструменты используя мозг а не стадный инстинкт…
    • –3
      так и знал что любителей поездов заденет и станут беспощадно минусовать :)
    • +1
      с масштабируемостью тоже всё в порядке — habrahabr.ru/post/170033/

      топик и коменты вообще читали? :))
      Теперь мы знаем, что руби может держать миллион мертвых соединений всего за 13ГБ памяти. Теперь заживем!

      … При том, что количество запросов в секунду равно около 150....


      какой толк от всех этих конекшенов если больше 150-и в секунду не переварит? Короче 10к тут и не пахло

      а так этож вы написали ))
      • 0
        устал повторять… 150-200 зпс обрабатываются в то время как держатся подключёнными миллион клиентов!
        при 100к подключённых клиентов обрабатываются 4к запросов в секунду — raw.github.com/slivu/1mc2/master/results/requests-per-second.png

        и это чисто лабораторный тест призванный доказать что Ruby решения таки можно масштабировать, а не то что он может быстро обрабатывать запросы.
        • 0
          я понимаю что другие конекшены висят, но я не вижу в этом ничего сверхъестественного если библиотека изначально проектировалась под асинхронный ввод-вывод.
          4к на 100к наверное нормально…
  • +2
    В общем то неплохо, но хотелось бы более конкретных примеров. Например, что так тормозило в руби/рейлс: память, робота с сетью, кривая архитектура, насколько стало сложнее/проще саппортить проект. Просто вода.
  • +7
    А чем к примеру Go лучше Python+Gevent?
    • +8
      Их не поддерживает Google, да и названия длинные, не модные.
    • НЛО прилетело и опубликовало эту надпись здесь
      • –6
        это зависит от компилятора и интерпретатора. Сам интерфейс языка и его возможности от этого никак не заыисят. А интересует именно разница между возможностями. Я часто в работе использовал Gevent и это наверно самый лучший и удобный фрейм для Python. Вопрос в том что такого может предложить Go. Тем более учитывая что язык новый, то либ для него довольно мало а это накладывает дополнительное время на разработку.
        • +13
          Вопрос в том что такого может предложить Go.


          В Golang возможности фреймворка Gevent заложены в дизайн самого языка.

          это зависит от компилятора и интерпретатора


          Интерпретируемый динамически типизированный (python) VS. компилируемый статически типизированный (golang). Более высокая скорость работы первого возможна только при повышенной криворукости разработчиков компилятора второго.
          • –6
            Очень не факт, коечто еще зависит от архитектуры, ибо архитектура всегда накладывает свои ограничения.

            Ну судя по тестам, разработчики там достаточно криворукие + небольшое комьюните. А для Python к примеру есть модуль в составе boost для написания библиотек на Си++, что довольно просто позволяет обрезать узкие места с которыми несправляется сам Python. К тому же есть еще Pyrex.

            Судя по всему этому я реально не вижу какогото выиграша. Посему вот интересно, почему выбрали именно Go, что на это побудило, и что в итоге они поняли после того как написали на нем сервис.
            • +2
              коечто еще зависит от архитектуры, ибо архитектура всегда накладывает свои ограничения

              Архитектуры чего?
              Ну судя по тестам, разработчики там достаточно криворукие

              Benchmark-и в студию тогда. Судя по public тестам — вполне себе адекватные.
              А для Python к примеру есть модуль в составе boost для написания библиотек на Си++

              Разговор сейчас о Python/Go, а не о C++. Писать модули для Python на C/C++ — занятие достаточно геморное (повторять этот опыт уж точно не хочется).
              Судя по всему этому я реально не вижу какогото выиграша

              «все это» — это «достаточно криворукие» разработчики в google и «модуль в составе boost»? Необычный подход к выбору технологии.
              • –6
                Равнять с питоном 3м смысла нет, юзают по сути 2.6-2.7.

                Тесты на математическую производительность логично что будут в пользу Go. А вот тесты на парсинг джейсона, на работу сервера, чтение файлов… собственно то что в основном используется во всех языках были бы куда интересней. В нете особо четких тестов нет, есть тока куски разные но народ говорит не в пользу Go.
                Вот какой то тест по сервакам http://ziutek.github.com/web_bench/. Там нет чистого Gevent. посему скажу что по тестам между питоновскими серваками gevent тянет вдвое больше чем Tornado, что больше Go http
                • 0
                  По приведенной ссылке, Go везде стоит на первых позициях. А говорить, что gevent тянет вдвое больше без тестов — не очень конструктивно.
                • +3
                  Вы абсолютно не понимаете в чем разница между статически и динамически типизированными языками.
            • +14
              При прочих равных — это всегда факт.

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

              Когда нужно было быстро и эффективно разрабатывать и развивать приложение, ребята использовали Ruby/RoR. Когда архитектура стабилизировалась и объем обрабатываемых данных начал расти, пришло время оптимизации скорости.

              Это абсолютно нормально. Это стандартный этап жизненного цикла высоконагруженных приложений.

              Некоторые на этом этапе начинают переписывать критичные места систем на Си, а то вообще на Assembler. Это приводит к серьезному усложнению. Появляется зоопарк используемых инструментов. Систему становится сложно сопровождать из-за этого. Типовая проблема…

              Эти ребята решили вопрос кардинально. Переписали на Go. И в своём конкретном случае не прогадали.
              Вовсе факт, что для других проектов переписать на Go будет правильным решением и даст такой же результат. Просто ребята обращают внимание тех, кто еще не разучился думать, что есть такой вариант решения проблемы. Что выбрать — это уже ваше решение.

              А RoR — с ним всё в порядке. Он в случае этих ребят успешно выполнил свою работу. Мавр сделал своё дело, мавр может уходить…
              • 0
                я помню на бейсике писал успешные проекты, но это не причина говорить что он хорош. Мне по этому и интересно сравнение Go и Python. Итнересно узнать глубинную разницу от людей которые положили на этот язык толпу юзеров. И есть ли большая разница в итоге между этими двумя языками. Ибо если нет, то комьюнити решает.
                • 0
                  Раз проекты были успешные, значит бейсик был хорош для вас, для вашего уровня знаний тогда… Это самый объективный критерий. Тот самый случай, когда победителей не судят…
                • +2
                  И есть ли большая разница в итоге между этими двумя языками.

                  Между этими языками просто катастрофическая разница. И помимо очевидного (python / go):

                  динамически типизированный / статически типизированный
                  интерпретируемый / компилируемый
                  ооп / «не-опп»

                  (а это уже очень большая разница), golang по дизайну предначначен для написания concurrent кода с последующей параллелизацией выполнения. Последнее различие фундаментально и изначально ставит языки по разным углам. При таком количестве различий — сравнивать языки без привязки к задаче — не имеет никакого смысла. Python с Ruby можно сравнивать без контекста — потому что там общих черт больше, чем различий. А Golang намного ближе к Erlang — тут сравнение было бы конструктивным.

                  P.S. Предвидя возможный возражения, скажу сразу — задача «написать сервер» слишком общая. А если уже сравнивать с gevent-ом, то event-based concurrency внутри одного thread-a всегда будет уступать возможностям собственного планировщика с возможностью работать на нескольких ядрах.
                  • 0
                    Чем вам Гоу не ООП?
                    • 0
                      Нет иерархии типов (и наследования, естественно). Вот этот пункт из FAQ и некоторые последующие.
                      • +1
                        Я хорошо знаю Гоу, спасибо.

                        Не понимаю только почему нет наследования, я вполне могу включить один struct в другой у получить у последнего всё что есть (публичного) у родительского.
                        • –2
                          Естественно, вы можете и на C писать, выкручивая себе руки и голову так, чтобы воссоздать функционал классов и наследования там, где создатели языка его не предполагали. Только язык не будет помогать вам это делать, ибо у него другая семантика. Как говорится «на Pascal-e можно писать на любом императивном языке», так и «ооп можно всунуть в любом императивный язык, были бы структуры». Это не делает дизайн языка хоть сколько-нибудь ООП-шным.
                          • +1
                            Всё верно, только к Гоу это не относится. Расширение сктруктур это не костыли, это так задумано.
                            • +1
                              Вы не поняли, я нигде не писал «не-ооп» это плохо. Мне нравится такой подход в организации кода и я его использую. Но это не отменяет того, что семантика языка явно не предоставляет механизмы для работы «внутри» ООП парадигмы.
                              • 0
                                Наверное мы на разных языках говорим. В Гоу структуры и есть объекты.
                                • 0
                                  Судя по всему, на разных. Объекты != ООП
                                  • 0
                                    Структуры в Гоу = объекты
                                    Структуры в Гоу умеют наследовать

                                    вывод: объекты в Гоу умеют наследовать.
                          • 0
                            В Go нет наследования, и это хорошо :)
                            В Go есть duck-typing при статической типизации — и это просто волшебно.
                            «инкапсуляция, наследование, полиморфизм» (tm) :)
                            Инкапсуляция есть, наследования нет, полиморфизм есть
                            еще есть интерфейсы, duck-typing и расширение структур
                            вполне себе ООП, просто не Java
                            • 0
                              Тот же комментарий, что и выше. Я и не говорил, что это плохо. ООП без наследования теряет свою суть чуть более чем полностью. Инкапсуляция и полиморфизм касаются других парадигм не в меньшей степени (а иногда и в большей), чем ООП.
                            • 0
                              Почему наследования-то нет? Есть же.
                            • 0
                              [sarcasm]Не ява — это, пожалуй, самый большой минус… а еще не руби и не питон… ужасно просто… плохой язык. А еще к Го имеет отношение Гугл — это вообще ужасно, ведь Гугл выпиливает Ридер.

                              Единственное, что есть в Го хорошего — это что Го — вообще ни разу не пхп.[/sarcasm]

                              Ужасно. Я думал, что Го языковые холивары не коснутся. Ан нет…
                              • 0
                                Гоу прекрасный язык, чего уж там?
                                • 0
                                  Сарказм?
                                  • +2
                                    Нет, мне он нравится.
                  • 0
                    А Golang намного ближе к Erlang — тут сравнение было бы конструктивным.
                    Да ладно ближе… Ваще разные.
                    Erlang это FP, изолированные процессы-акторы, интерпретируемый, динамическая типизация. Go-императивный, зеленые потоки (как понимаю — не изолированные), нативный код, статическая типизация.
                    • 0
                      И там и там — изолированные. И там и там — с собственным scheduler-ом(ами). И там и там общение через обмен сообщениями (только механизмы адресации сообщений разные). Общий подход к обеспечению concurrency — это серьезная overlap между языками — гораздо больший, чем между go и ruby.
                      • 0
                        Если в Go процессы изолированные, то почему это работает? play.golang.org/p/WLIKjXeUNl

                        package main
                        
                        import (
                        	"fmt"
                        	"time"
                        )
                        
                        type Shared struct {
                        	Value int
                        }
                        
                        func add(t *Shared) {
                            t.Value += 1
                        }
                        
                        func main() {
                        	t := Shared{0}
                        	t.Value = 0
                        	fmt.Println(t)
                        	for v := 0; v<10; v++ {
                        		go add(&t)
                        	}
                        	time.Sleep(10 * time.Millisecond)
                        	fmt.Println(t)
                        }
                        

                        Выводит
                        {0}
                        {10}
                        
                        • +1
                          Ни разу не изолированые, более того, передавать по каналам указатели — весьма идиоматично.
          • –1
            у python есть компиляция и есть вариант со статической типизацией (для ценителей). На удивление — это мало влияет на производительность в общем случае. Для того, чтобы ускорить код, переключившись на статическую типизацию, нужно заметно улучшить качество кода. Как показывает опыт — оплатить труд программистов, которые напишут код качественно — значительно дроже, чем оплатить еще N+X серверов. Это правило работает до определенных пределов, так как масштабирование «в лоб» не работает почти никогда, рост производительности растет обычно по обратной геометрической функции. Просто большинство кодовых инсталляций не доживает до того, как начинаются проблемы с масштабирование.
          • –1
            Вы не правы. Динамические языки прекрасто справляются со своими динамическими проблемами благодарю JIT'у. Другое дело, что статические компилируемые языки можно сразу оптимизировать, а JIT'у надо дать время прогреться.

            Вот тут автор прекрасно это объясняет: speakerdeck.com/alex/why-python-ruby-and-javascript-are-slow
      • –10
        Python
        python yourfile.py

        и в результате файл с байт кодом, который не слишком отстает от java
        • +7
          Вы что-то путаете. Разница между python vm и jvm, как между вертолетом-игрушкой на ИК-управлении и настоящим Ка-50.
          И то, и то летает; и там, и там винты… Но немножко по разному и под разные задачи.
      • –2
        Беглое сравнение производительности go и питона показывают не самые впечатляющие результаты. Парсер json и движок регулярных выражений оказались медленнее встроенных питоновских (не говоря уже об ujson). А еще не забываем об pypy.
    • +1
      Отсутствием GIL? Наличием многопоточности, которая приносит реальные профиты. Статической типизацией, которая ловит ошибки на этапе компиляции, а не во время исполнения.
  • +6
    Руби, Пизон, Го, хостинг Амазона, Нода.джс… Все пройдет, а ПХП останется =)
    • +3
      не дай бог)
    • –2
      Если судить по времени появления, то это скорее пыхи — «временный тренд», во всяком случае по сравнению с питоном :)
    • 0
      Пизон? Чего ж тогда не раби и не пихипи, или как еще можно исковеркать название?
      • 0
        У меня был знакомый, который учил английский, похоже, в турецкой школе. И он всегда произносил «энджайнкс» и жутчайше злился, когда кто-то его называл иначе. А злился он очень забавно — так, что все старались почаще разговаривать про nginx. Надо бы позвонить ему…
        • 0
          Одно дело, когда все произносят «питон», а не «пайтон», а другое, когда кто-то говорит «раби» или «пизон». Это ж что надо употребить, чтоб такое пришло в голову?
          • 0
            Ну лично мне «пизон» понравился… если честно, я даже гуглить стал, чтобы узнать, что это такое ))
  • +1
    Мне интересно, если бы они отказались только от рельсов, а написали бы все на чистом руби, какой прирост это дало бы?
    • –3
      на порядок
  • +4
    А почему не использовали sinatra? Он наверняка больше подходит под написание api.
  • +2
    как бы там не было — frontend у них остался на Rails (при этом не самые новые Rails).
  • +1
    Чем то похоже на эту тему coderwall.com/p/5cafjw :)

    Ну на самом деле они просто выбрали неправильный инструмент. Если нужна производительность то нужно использовать сервера с неблокирующим IO, либо параллелизировать через акторы, нарпимер celluloid.io/. А лучше все вместе. Ну и конечно же jRuby и Rubinius с нормальными threads.

    На своем проекте мы используем Goliath и он работает очень шустро.

    Ссылки в тему:

    celluloid.io/
    github.com/celluloid/reel

    goliath.io
    github.com/mperham/rack-fiber_pool

    jruby.org/
    rubini.us/
    • +4
      3 года назад ни целулоидов ни голиафоф не было а если и были то в зачаточном состоянии. Мне кажется для них все получилось нормально. Код стал устаревать и его зарефакторили просто на другом языке, а это значит устранили узкие места, которые могли быть не видны в начале проекта.
      • 0
        Вполне вероятная история
    • 0
      А вы уверены, что CPU съели контекст-свичи и неблокирующий IO исправил бы ситуацию? Может CPU съедался оверхедом рельсов?
  • +7
    А мне тоже Go понравился. Я понимаю, что сообщество маленькое, что бибилотек маловат (я в курсе что судя по списку есть все и даже больше, но это все слабо поддерживается и судя по звездам мало кому нужно) и это огорчает. Язык судя по всему большинство пытается использовать в web-разработке, и создателям крайне необходимо взять все требуемые либы под свое крыло, иначе с уверенностью будет туговато.
    • 0
      Сообщество маленькое, но крепкое. В #go-nuts на irc.freenode.net всегда помогут по любым вопросам.
      • 0
        Оно конечно так, ну либ мало, а то что есть особо не поддерживается и создателей тут даже винить не стоит, судя по репам не сильно много нуждается в них. По этому когда думаешь может что-нибудь написать, а потом понимаешь, а кому оно надо будет. Кроме того есть канторы, которые заявляют что «мы используем», но выкладывать свои наработки они не хотят, возможно по тем же причинам, а возможно выкладывать особо не чего.
  • +3
    Хотелось бы услышать больше о том чем плох java. Я не пишу на нем, просто интересно
    • +5
      Не модно использовать Java, вот Go, node.js, RoR, другое дело.
      • +2
        Java уж очень многословная. Да и оракл нынче дыры заделывает с реактивной скоростью.
        • +3
          Да ладно Вам, 7u17 уже ,)
        • +5
        • –2
          Кто искал дыры в Go? Или можно думать, что их там просто нет?
          И Оракл заделывает дыры не во всей Java, а в апплетной части.
        • 0
          Условная «многословность» Java в полной мере компенсируется мощными IDE.
    • +2
      как я понял из последнего абзаца авторов напряг большой размер хипа, у джавы он будет где-то в 3 раза больше чем у c++, хотя в go тоже сборка мусора автоматическая. Ну и джавистам платить нужно было бы, а на go, как я понял, сеньёры были готовы писать по сути за еду :)
      • +1
        Наврядли кто-то там будет готов за еду — народу мало, а значит будут качать права. Просто язык относительно новый и если зайти на официальный сайт, то синтаксис можно освоить моментально, а либ достаточно немного. По этому обучится каждый сможет в кратчайшие сроки.
    • +1
      В java мало возможностей, позволяющих писать код лаконично. Ну и долгая перекомпиляция тоже не радует. Да, есть всякие JRebel, но это костыли. В Go, конечно учтен этот недостаток — язык изначально делали так, что бы компилятор мог собирать молниеносно.

      PS. Пишу на java более 5 лет
      • +2
        долгая перкомпиляция фиксится компьютером по-мощнее :)

        p.s. пишу на java от заката до рассвета и наоборот и не использую тяжеловесную ненужную требуху типа WebSphere и Weblogic, чувствуя себя с ней довольно комфортно и не испытываю каких-то проблем со скоростью разработки.
        • +1
          Компьютер «по-мощнее» есть, но я бы не сказал, что фиксит проблему, все равно долго. А такой вопрос: вы писали на каких-нибудь других языках, с быстрым циклом разработки (Go, PHP, Ruby, Python, etc)?
          • +2
            Быстрый цикл разработки не гарантирует быстрого выпуска продукта
            • 0
              Не гарантирует, но веб-деве весьма способствует. Разработка реально идет быстрее.
          • 0
            Я писал на PHP какое-то время назад и в начале действительно проще и быстрее. Но это начало длится очень недолго. Какой-то серьезный проект я бы не стал писать на PHP/Ruby/Python. Это связано с тем, что потом поддерживать эту систему будет адски сложно когда она разрастется. Хотя нет, если бы это был проект «на выброс» из одной странички, то может и стал бы.
            А проект по типу интернет магазина уже не стал бы.

            Скорость разработки это не только скорость того, как скоро увидишь свои изменения после изменения в коде, но и то, как эффективно ты сможешь поддерживать код и то, как быстро ты сможешь заделиверить фичи и то, как быстро ты сможешь выполнить требование о том, какую нагрузку твоя веб-аппликация/веб-сервис должен тянуть.
            • 0
              А на чем бы Вы, например, уже интернет магазин реализовали бы, позвольте поинтересоваться? Я так понимаю, что PHP/Ruby/Python Вы не рассматриваете для реализации таких сложных проектов?
              • 0
                На Java любимой.

                Если интересует чуть глубже, то:
                Контейнер Tomcat или Jetty, для веб-морды Spring MVC или Struts 2, персистенс — Hibernate или MyBatis или Spring JDBC.
                На требования нужно смотреть что бы сказать точнее в пользу чего склонился бы.
                • 0
                  Наверное это нечто волшебное, по сравнению с PHP/Ruby/Python… наверное код на Java волшебным образом не разрастается (цитата: «потом поддерживать эту систему будет адски сложно когда она разрастется»).

                  Всегда предполагал, что все-таки качество кода и способность его дальнейшего сопровождения в очень большей степени зависит от разработчика. Ан нет, оказывается есть еще чудеса на свете!
                  • +1
                    Код как раз разрастается.

                    Для меня лично при увеличении кодовой базы, то что творится в коде на Java/[другом языке со статической типизацией] понимать легче, чем то, что творится с кодом с динамической типизацией. Легче допиливать новые фичи и фиксить баги.
                    А теперь представьте себе поддержку интернет банка который написан на PHP и сменилось несколько поколений разработчиков. И код там разного качества. Как легко и просто это будет поддерживать?
                    И вам нужно впихнуть какой-то новый функционал. У вас есть пару десятков разрозненных модулей и вам нужно удалить часть старой фунциональностей и заменить на новый. Если мой проект на Java, то у меня что-то просто нескопмилируется где-то и я узнаю об этом раньше, чем это выйдет на продакшн(в общем случае, если не использовать Reflection, за необоснованное использование которого нужно люлей вставлять).

                    Я полностью согласен с тем, что качество кода зависит от девелопера.
                    Я говорю немного о другом. О том что после того, как проект пересекает какую-то черту по фичам/размеру кодовой базы, сложность дальнейшей его поддержки и внедрения новых фич на Python/Ruby/PHP становится на порядки сложнее, чем на Java/[другом языке со статической типизацией].
                    • 0
                      Уповать только на то, что компилятор что-то не пропустит? Довольно сомнительно. Гораздо чаще дело не в типах, а в стиле написания кода (трудность для дальнейшего сопровождения) и все-таки в логике работы приложения.

                      Могу точно так же перефразировать: «А теперь представьте себе поддержку интернет банка который написан на Java и сменилось несколько поколений разработчиков. И код там разного качества. Как легко и просто это будет поддерживать?». Ключевое тут: «сменилось несколько поколений разработчиков» и «код там разного качества».
                      • 0
                        Между уповать и иметь гарантию огромная пропасть ;)

                        Интернет банков на PHP написанных слава богу я не видел. На Java видел и жить с этим можно.
                        • 0
                          Вы действительно считаете, что строгая типизация гарантирует Вам корректность работы программ?
                          Дальше, в принципе, можно не продолжать диалог. Спасибо за содержательные ответы.

                          • 0
                            Ничто не гарантирует ничего. Строгая типизация ПОМОГАЕТ. Не более.
                            • 0
                              Согласен. Слабая типизация языка требует от разработчиков более высокой культуры кодирования, если хотите (следование разработанным conventions, coding standards и тп). В противном случае получится неструктурированная каша.

                              Правда, из этого следует, что строгая типизация помогает сохранять структуру приложения (что важно для поддержки кодовой базы), но не гарантирует корректность.
        • +2
          пишу на java от заката до рассвета

          Вот! А писали бы не на Java, еще и время на сон оставалось бы.
          • 0
            это я так сказал :)
            работаю я в течении рабочего дня. Ключевое слово работаю. Проекты по срокам тоже не прогорают.
      • +3
        Java — это не только и не столько язык, сколько платформа: JVM, библиотеки, фреймворки, сборщики, продукты, etc. И это дерьмо постоянно растет, но нисколько не совершенствуется. И проблема в том, что сейчас на голой джаве уже практиески никто не пишет. Все современные архитектурные шаблоны на java ведут к наворачиванию технологий распуханию аппликации. Вот пример для простой вебапликации: JBoss+SpringMVC+EJB+JPA+JSP+Maven+Arquillian. И это не предел. Естественно что разработка со всем этим дерьмом будет еле ворочаться. Но тем не менее, сама компиляция в Java очень быстрая.

        P.S. Хочется писать лаконичнее — возьмите к примеру Groovy, XTend или Kotlin.
        • +5
          аппликации
          <snob>Примите мои конгратуляции!</snob>
        • 0
          Далеко не в каждое приложении на Java нужно тащить половину JaveEE стека.

          Насчет «будет еле ворочаться» можно вспомнить пример «быстрой» hypertable на C++, которая в отличии от «медленной» HBase не только медленнее, но и не работает почти)
        • 0
          Если держать себя в руках, то все хорошо: можно без проблем использовать чистую джаву и playframework, например.
        • +3
          Ну не все дерьмо. Можно и не использовать JBoss, EJB, Arquillian и прочую энтерпрайз money hungry херню когда это не нужно.
          Можно стек и упростить. Многие приложений не неуждаются в полноценном Апп Сервере с поддердкой J2EE, хватает тех фичей что предоставляют сервлет контейнеры Jetty/Tomcat. Да и по сути по мере надобности можно тот же JMS etc прикрутить к Jetty/Tomcat'у.

          P.S. Scala тоже очень ничего.
      • 0
        Что ж вы там компилируете такое? Мой проект с 5k классами полностью компилится за 8 секунд.
      • 0
        долгая перекомпиляция тоже не радует
        Мне всегда казалось, что компилятор java очень быстрый (особенно, по сравнению с c/c++). Ведь он не требует повторных запусков, самостоятельно разрешая зависимости на уровне кода и кешируя информацию о уже скомпилированных классах. Думаю, большую часть сборки вашего приложения занимает maven и многократная архивация, ведь java-инфраструктура использует архивы в архивах.
        К примеру, собирал как-то java-порт BerkelyDB. В нём около тысячи классов, а ant собрал всё на моей не особо мощной машине за ~11 сек.
    • 0
      Вопрос слишком общий, все зависит от конкретной задачи
    • +6
      Java ничем не плоха. Просто некоторые не умеют ее готовить.
  • –9
    А вы действительно переписали API — Application programming interface? Или всё таки его реализацию?
  • +2
    C++

    Что может быть лучше классики?
    • +2
      Возможно причина в том что существующие разработчики быстрей переучатся на Go (сами зайдите на офф. сайт и удивитесь как все просто). Ну и в плане скорости разработки думаю C++ проиграет.
    • +1
      Переучиться на С++ сильно сложнее, очевидно же.
  • +7
    Нет ничего лучше, чем языковой холивар в пятницу с утра. Бессмысленный, беспощадный и бесполезный.
  • +3
    «Чем бы дети не баловались, лишь бы новые языки не писали.»

    Вообще я рад за ребят, что у них всё получается и им нравится то, что они делают. На этом все. Никаких дополнительных выводов для себя сделать не могу в виду отсутствия какой либо полезной информации.
  • 0
    Ушел на сайт Go, посмотрел презентацию, счкачал, учу.
  • +1
    Очень интересно какие были претензии к Erlang.
    • –1
      скорее всего не осилили то ли OTP, то ли функциональную парадигму в целом.
      • +1
        Меня всегда удивляют подобные комментарии. Почему сразу «слабаки! ниасилили»? Крупный и успешно развивающийся проект, почему вы считаете, что там сидят недоразвитые имбицилы, которые принимают решение на уровне «асилил/ниасилил»?

        Между erlang/golang есть объективная разница (как на уровне языка, так и на уровне платформ(ы) для разработки) — у каждого свои плюсы/минусы. И даже если решение было принято не на основе этих объективных причин, а, например, на уровне «команда увереннее чувствует себя на go» (что вполне субъективно) — то в этом нет ничего плохого.
        • 0
          Почему сразу «слабаки! ниасилили»?
          Да, почему? Я предположил, что у них не получилось добиться существенных результатов за разумное время, не более.
      • 0
        Erlang совсем не сложный язык (не сравнить с C++, Haskell или Scala), да и в OTP ничего сложного нет. Очень маловероятно, что причиной выбора Go было неосиляторство.
      • 0
        Скорее попали на такого себе консультанта, или вообще попытались взять тему «с набега» и не вписались во время отведенное для рассмотрения вопроса.
    • 0
      Подозреваю, проблема с Erlang'ом была в том, что тот не приспособлен под хоть сколько-то содержательную императивную логику — там удобно разве что фильтровать и перенаправлять потоки данных. Ну и производительность, очевидно, ниже.

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