Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 275
«Все в порядке, его поддерживает Google», и Reader тоже поддерживала Google. Прошу прощения, не могу отойти от сегодняшнего.
Когда Google перестанет поддерживать Google Reader, тот просто перестанет работать.
Если Google перестанет поддерживать Go, тот будет точно так же работать и дальше.
Если Google перестанет поддерживать Go, тот будет точно так же работать и дальше.
Вашими бы устами да мед пить. Кому нужна неподдерживаемая платформа?
Платформа не прекратит существование в один день. Она будет работать и дальше. Ваши сервера не выключатся. Да, вам станет труднее найти новых специалистов для её поддержки в будущем. Но ваш бизнес будет работать, клиенты не убегут узнав, что Google прекратил поддержку Go.
Или вам в одночасье станет противно работать с платформой, которая ещё вчера всем устраивала? :)
Или вам в одночасье станет противно работать с платформой, которая ещё вчера всем устраивала? :)
И не будет развиваться, как, например, ReiserFS
Все в порядке, гугл поддерживает gwt. Подсадили пол мира на него и бросили.
jruby не не слышали
Минуса за формулировку вполне оправданы, но мне тожe интересно, дал бы эффект переход на jruby.
Я бы хотел посмотреть сравнение скоорости, неужели python сильно медленнее Go, а comunity у него огромное.
Вы хотите сравнить скорость работы компилируемого и исполняемого языков? Сразу могу сказать, разница будет в 10-20 раз.
Нет никакого смысла сравнивать скорость работы кода. Нужно сравнивать скорость работы программ, выполняющих одинаковые задачи. Ну какой прок от того, что go быстрее складывает 2 числа, задача выбрать из базы данные и отдать их в json? И вот тут у go не все так радужно: стандартная библиотека довольно медленная.
Это уже частности, в разных языках есть разные косяки в библиотеках, можно для каждого языка подобрать неудачный пример. Последний раз когда я анализировал разные базы данных, у отдельных языков программирования был полный швах в скорости работы с МонгоДБ из-за библиотек. Но в целом компилируемые языки на порядок быстрее просто из-за своей природы.
Пруф?
Разница не будет такой большой. Иногда вообще нет разницы. Иногда байткод быстрее (и теоретически и практически).
Но вот в случае с языком Си можно добиться хорошего выигрыша в производительности, по сравнению динамическими языками, управляе выделением и освобождением памяти самостоятельно.
Разница не будет такой большой. Иногда вообще нет разницы. Иногда байткод быстрее (и теоретически и практически).
Но вот в случае с языком Си можно добиться хорошего выигрыша в производительности, по сравнению динамическими языками, управляе выделением и освобождением памяти самостоятельно.
Не касаясь остальной ветки, замечу, что в бенчмарках по ссылке стандартная ошибка при тестировании Java: отсутствие прогрева. Может, на тривиальном примере, как там, это бы и не сказалось, а на сравнении любых программ, состоящих более чем из одной функции, это сказывается.
Да, действительно в этом примере результат впечатляющий. Хотя сказалась опять же упревление памятью. Вынес декларацию переменных из цикла в Perl, время упало с 19 до 15 сек на моей машине.
Вот пример работы со строками raid6.com.au/~onlyjob/posts/arena/ там вообще Perl обгоняет Си.
Вот пример работы со строками raid6.com.au/~onlyjob/posts/arena/ там вообще Perl обгоняет Си.
А за счёт чего байткод может быть быстрее?
В теории — например, если байткод вместе с его интерпретатором лучше влезают в кэш процессора, чем нативный код.
На практике — есть JIT, он сможет скомпилировать часто используемый кусок байткода в нативный, с нужными оптимизациями (он будет знать какая ветвь там чаще выполняется).
Или может дело в библиотеках. Например в Perl — массив имеет некоторое количество памяти выделенное до него и после него, поэтому нормально (быстро) работает как стэк или очередь. Так что если взять и написать «простую» программу где используются обычне массивы без всяких библиотек, то Сишный массив может проиграть.
А если в Си постоянно использовать библиотеку с самыми умными массивами которые только может быть, Си потеряет преимущество контроля за выделением/освобождением памяти (очень медленная операция по сравнению с арифметикой).
вот в примере raid6.com.au/~onlyjob/posts/arena/ показано что Перл быстрее Си в операциях со строками.
На практике — есть JIT, он сможет скомпилировать часто используемый кусок байткода в нативный, с нужными оптимизациями (он будет знать какая ветвь там чаще выполняется).
Или может дело в библиотеках. Например в Perl — массив имеет некоторое количество памяти выделенное до него и после него, поэтому нормально (быстро) работает как стэк или очередь. Так что если взять и написать «простую» программу где используются обычне массивы без всяких библиотек, то Сишный массив может проиграть.
А если в Си постоянно использовать библиотеку с самыми умными массивами которые только может быть, Си потеряет преимущество контроля за выделением/освобождением памяти (очень медленная операция по сравнению с арифметикой).
вот в примере raid6.com.au/~onlyjob/posts/arena/ показано что Перл быстрее Си в операциях со строками.
Кто-то может объяснить, что случилось с руби? Вроде ещё недавно холивары были что лучше руби vs python, если совался с php, то заклевывали моментально.
Сейчас такое ощущение, что со всех сторон плевки на руби идут. Что произошло?
Сейчас такое ощущение, что со всех сторон плевки на руби идут. Что произошло?
Мода прошла
Ага. Люди поняли, что писать сайтики для двух людей на руби прикольно, а вот высоконагружённые приложения — совсем не айс. И он годится только потешить своё удовольствие.
Совершенно не согласен.
С Ruby и Ruby on Rails все как раз айс и даже больше!
Руби набирает все большую популярность и постоянно развивается в лучшую сторону.
Сам пишу на RoR и каких-либо тормозов не замечаю.
«Сейчас такое ощущение, что со всех сторон плевки на руби идут. Что произошло? » — не то и не там читаете, вот что произошло. Я не видел вообще никакого негатива в сторону Ruby.
Вполне возможно, чтоидолопоклонники приверженцы php вряд ли могут вам сказать что-то хорошее о Ruby, оно и понятно — Ruby давно уже заткнул за пояс php по производительности, а это был наверное единственный аргумент в пользу php когда-то.
С Ruby и Ruby on Rails все как раз айс и даже больше!
Руби набирает все большую популярность и постоянно развивается в лучшую сторону.
Сам пишу на RoR и каких-либо тормозов не замечаю.
«Сейчас такое ощущение, что со всех сторон плевки на руби идут. Что произошло? » — не то и не там читаете, вот что произошло. Я не видел вообще никакого негатива в сторону Ruby.
Вполне возможно, что
Ruby давно уже заткнул за пояс php по производительности
benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=yarv&lang2=php
Что сказать-то хочешь?
хотя бы то, что тесты должны быть абсолютно идентичными в коде, это во-первых
во-вторых — если даже на простейших тестах видна такая значительная разница, я не думаю, что на более сложных тестах что-то должно кардинально измениться.
хотя да, согласен, нужно будет написать еще пару-тройку тестов — структуры (деревья, списки), массивы, строки, регулярки — чтобы уж точно было более убедительно
во-вторых — если даже на простейших тестах видна такая значительная разница, я не думаю, что на более сложных тестах что-то должно кардинально измениться.
хотя да, согласен, нужно будет написать еще пару-тройку тестов — структуры (деревья, списки), массивы, строки, регулярки — чтобы уж точно было более убедительно
> тесты должны быть абсолютно идентичными в коде
Тесты должны использовать все преимущества языка.
Тесты должны использовать все преимущества языка.
назовите мне хоть одно преимущество php, по которому он будет проходить тест быстрее других языков программирования?
именно поэтому я и написал тесты, которые повторяют код друг друга в точности, но на разных языках
именно поэтому я и написал тесты, которые повторяют код друг друга в точности, но на разных языках
преимущества, говорите?
вот специально сейчас глянул на исходники тестов на benchmarksgame.alioth.debian.org и сравнил…
совершенно странно, почему обычные циклы в php сравниваются с итераторами в Ruby? Итераторы — это более медленный механизм, хотя и более мощный несомненно. Давайте тогда уж будем до конца честными — заменим все итераторы в коде теста Ruby на обычные циклы и тогда уж сравним.
вот специально сейчас глянул на исходники тестов на benchmarksgame.alioth.debian.org и сравнил…
совершенно странно, почему обычные циклы в php сравниваются с итераторами в Ruby? Итераторы — это более медленный механизм, хотя и более мощный несомненно. Давайте тогда уж будем до конца честными — заменим все итераторы в коде теста Ruby на обычные циклы и тогда уж сравним.
Замените. Насколько я знаю, патчи приветствуются.
Оно мне надо?
Мне достаточно собственной уверенности, а остальным стоит задуматься — а всему ли надо так безоговорочно верить? Зачастую не лишне и перепроверять.
Мне достаточно собственной уверенности, а остальным стоит задуматься — а всему ли надо так безоговорочно верить? Зачастую не лишне и перепроверять.
Ну гундеть и порть горячку вам надо, а поправить не надо. Вот так и живем.
Стандартный ответ: «Сам дурак!», когда нечего уже возразить, остались лишь эмоции и слюни. Знакомо ;-) Не утруждайтесь в оскорблениях — все-равно мимо.
Просто я всегда пытаюсь разобраться, а не просто верить всему на слово.
Просто я всегда пытаюсь разобраться, а не просто верить всему на слово.
Просто я всегда пытаюсь разобраться, а не просто верить всему на слово.
Пока что ваша теория подкреплена только вашими словами и больше ни чем. Так что, большинство поверить тем тестам, а не вам. Хотя возможно вы и правы.
Я не собираюсь разбиться об стену, только лишь кому-то доказать свою правоту. Дело каждого — кому и во что верить.
Но, следуя хотя бы простейшей логике, если даже в простейших алгоритмах есть пройгрыш в производительности, то с какого перепугу вдруг должно произойти обратное на более сложных? Если размышлять здраво — любой сложный алгоритм — это совокупность более простых.
Моя теория подкреплена абсолютно идентичным кодом на разных языках программирования, в отличии от абсолютно различной реализации алгоритмов тестов на benchmarksgame.alioth.debian.org. Зачем вводить в заблуждение? Там более, что такой (вроде как) авторитетный источник.
Но, следуя хотя бы простейшей логике, если даже в простейших алгоритмах есть пройгрыш в производительности, то с какого перепугу вдруг должно произойти обратное на более сложных? Если размышлять здраво — любой сложный алгоритм — это совокупность более простых.
Моя теория подкреплена абсолютно идентичным кодом на разных языках программирования, в отличии от абсолютно различной реализации алгоритмов тестов на benchmarksgame.alioth.debian.org. Зачем вводить в заблуждение? Там более, что такой (вроде как) авторитетный источник.
Вы сами патчи туда присылали? Подтверждаю что это не правильные бенчмарки (по собственному опыту) +
habrahabr.ru/post/119579/
habrahabr.ru/post/119579/
Да сами проведите замеры и представьте публике, если лень патчи делать.
Вот, не поленился. Спасибо доброму человеку — предоставил код теста mandelbrot.
Сравнение производительности Ruby и PHP.
Не стоит все же всему безоговорочно доверять.
Сравнение производительности Ruby и PHP.
Не стоит все же всему безоговорочно доверять.
Мне казалось, в Руби jit. И всего 20%?
Вам именно казалось, а желательно все-таки знать.
А 20% на таком тесе — это очень даже не мало.
А 20% на таком тесе — это очень даже не мало.
Действительно, не могу найти точного указания на этот факт, хотя есть много упоминаний вскользь (хотя бы вот). Значит на самом деле там нет jit?
В тестах, где производится вызов метода объекта, пройгрыш PHP составляет около 50%, что фактически в 2 раза медленнее, чем Ruby.
Еще какие-то вопросы есть?
Еще какие-то вопросы есть?
Напомню, что реализаций ruby несколько.
MRI — JIT'а нет, его пока пытаются пилить.
JRuby — JIT самой JVM, сам JRuby пытается оптимизировать довольно много, чтобы позволить лучше работать JIT'у JVM. Дополнительно можно посмотреть здесь: github.com/jruby/jruby/wiki/JRubyInternalDesign.
Rubinius и MacRuby — имеют свой JIT.
IronRuby и Ruby.NET — используют JIT .NET CLR, насколько понимаю.
MRI — JIT'а нет, его пока пытаются пилить.
JRuby — JIT самой JVM, сам JRuby пытается оптимизировать довольно много, чтобы позволить лучше работать JIT'у JVM. Дополнительно можно посмотреть здесь: github.com/jruby/jruby/wiki/JRubyInternalDesign.
Rubinius и MacRuby — имеют свой JIT.
IronRuby и Ruby.NET — используют JIT .NET CLR, насколько понимаю.
Я имел в виду ту реализацию, которую использовал Sega100500, MRI.
Спасибо за напоминание, Капитан Очевидность!
Если бы я имел ввиду какую-то иную реализацию, я бы так и написал, тем более, что у них у всех различные названия, не так ли?
Если бы я имел ввиду какую-то иную реализацию, я бы так и написал, тем более, что у них у всех различные названия, не так ли?
Поскольку сам пишу на node.js, решил проверить, как дела в нём:
gist.github.com/AlexeyKupershtokh/5180271
gist.github.com/AlexeyKupershtokh/5180271
совсем некорректное сравнение, мне кажется
в JS используется JIT — конкретно в NodeJS — V8
я не специалист в NodeJS, поэтому эти выводы только с помощью гугл сделал
в JS используется JIT — конкретно в NodeJS — V8
я не специалист в NodeJS, поэтому эти выводы только с помощью гугл сделал
для примера, небольшое добавление простейшего динамизма в код 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 раз.
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 раз.
тут же увеличивает время выполнения кода JS на порядок (в 10 раз)!То, что нода с палками в колёсах все равно ездит в 3 раза быстрее ruby и php, как-то должно меня от нее отпугнуть? :)
Конечно же нет!
Вообще выбор ЯП — дело сугубо каждого.
Разве я собирался кого-то пугать? Вообще не агитирую за смену ЯП или системы разработки. Каждому — свое! К слову, JS мне вообще не нравится, я могу его терпеть только в виде JQuery максимум.
В начале я вообще привел сравнение 2-х (истинно) скриптовых ЯП, не предполагал, что это вот в такую ветку обсуждений растянется, да еще и придется дополнительные эксперименты проводить.
Но вывод я сделал — на хабре всем троллям не угодишь, которые норовят шмякнуть минус и вякнуть что-то.
Побольше бы таких, как вы — которые хотя бы реальные эксперименты проводят, чтобы убедиться в чем-то.
Вообще выбор ЯП — дело сугубо каждого.
Разве я собирался кого-то пугать? Вообще не агитирую за смену ЯП или системы разработки. Каждому — свое! К слову, JS мне вообще не нравится, я могу его терпеть только в виде JQuery максимум.
В начале я вообще привел сравнение 2-х (истинно) скриптовых ЯП, не предполагал, что это вот в такую ветку обсуждений растянется, да еще и придется дополнительные эксперименты проводить.
Но вывод я сделал — на хабре всем троллям не угодишь, которые норовят шмякнуть минус и вякнуть что-то.
Побольше бы таких, как вы — которые хотя бы реальные эксперименты проводят, чтобы убедиться в чем-то.
так, для общего развития… на простейших тестах JS проигрывает по производительности Ruby в 6-8 раз… проверил только на 1-ом тесте.
И, кстати, в фреймворках как раз достаточно интенсивно используются вызовы методов объектов и функций.
Все по-честному, без обмана у Волшебника Сулеймана — никаких «с палками в колёсах».
Но это ни в коем случае не должно Вас отпугнуть от использования NodeJS. Боже упаси!
Это просто я все пытаюсь провести разностороннее тестирование.
И, кстати, в фреймворках как раз достаточно интенсивно используются вызовы методов объектов и функций.
Все по-честному, без обмана у Волшебника Сулеймана — никаких «с палками в колёсах».
Но это ни в коем случае не должно Вас отпугнуть от использования NodeJS. Боже упаси!
Это просто я все пытаюсь провести разностороннее тестирование.
… хотя не везде так. В разных браузерах совершенно разная скорость. NodeJS не установлен, поэтому скорость проверяю в браузерах FireFox, Opera, Chrome.
провел еще несколько тестов…
нет, все же Javascript с V8 быстрее (что нисколько не удивляет, если верить Википедии: «Компиляция исходного кода JavaScript непосредственно в собственный машинный код, минуя стадию промежуточного байт-кода.».
Но самое интересное в том, что в Ruby запросто можно использовать этот движок V8, т.е. какие-то особо критичные до скорости алгоритмы можно запросто реализовать на нем, оптимизировать. Тест вычисления Фибоначчи с использованием V8 выполняется примерно в 7 раз быстрее. Такие вот дела.
нет, все же Javascript с V8 быстрее (что нисколько не удивляет, если верить Википедии: «Компиляция исходного кода JavaScript непосредственно в собственный машинный код, минуя стадию промежуточного байт-кода.».
Но самое интересное в том, что в Ruby запросто можно использовать этот движок V8, т.е. какие-то особо критичные до скорости алгоритмы можно запросто реализовать на нем, оптимизировать. Тест вычисления Фибоначчи с использованием V8 выполняется примерно в 7 раз быстрее. Такие вот дела.
1) Вы недавно говорили, что сравнивать компилируемые языки с некомпилируемыми, а теперь сравниваете.
2) Вы недавно говорили, что вам JS не нравится, а вот вы уже готовы писать на нём, да еще и без JQuery. Не говоря уже о том, что это будет внутри руби, что имхо еще хуже, чем писать на чистом языке.
2) Вы недавно говорили, что вам JS не нравится, а вот вы уже готовы писать на нём, да еще и без JQuery. Не говоря уже о том, что это будет внутри руби, что имхо еще хуже, чем писать на чистом языке.
1. Такой уж пытливый ум у меня — попытался выяснить причину этого превосходства. Всегда считал JavaScript скриптовым, а он вон как — перекочевал с помощью V8 практически в нишу компилируемых языков. Все потому, что никогда особо не интересовался JS, и не собираюсь в дальнейшем.
2. Не только говорил, но и говорю — не нравится мне JS, и воспринимаю его максимум в виде JQuery. На нем писать не собираюсь, не более того, чем это нужно будет в веб-приложении — всегда хватает небольших JS-вставок. Просто нашел способ оптимизации «узких мест» в программе на Ruby. Совершенно даже не призываю использовать это, просто такой способ есть — как факт.
Меня Руби устраивает во всем и полностью.
2. Не только говорил, но и говорю — не нравится мне JS, и воспринимаю его максимум в виде JQuery. На нем писать не собираюсь, не более того, чем это нужно будет в веб-приложении — всегда хватает небольших JS-вставок. Просто нашел способ оптимизации «узких мест» в программе на Ruby. Совершенно даже не призываю использовать это, просто такой способ есть — как факт.
Меня Руби устраивает во всем и полностью.
Плюсую. benchmarksgame.alioth.debian.org — это не бенчмарк.
Это бенчмарк * соревнование программистов что в итоге переодически даёт 0.
Видел как сравнивается одно выражение на ruby с циклом на perl, что явно фейк. Так же много где не удалось увидеть исходник (сайт глючил).
И судя по отзывам автор не очень дружелюбен, и в место того чтобы обеспечить честность бенчмарков говорит «присылайте патчи» и сам их отвергает если они лично ему не нравятся.
Это бенчмарк * соревнование программистов что в итоге переодически даёт 0.
Видел как сравнивается одно выражение на ruby с циклом на perl, что явно фейк. Так же много где не удалось увидеть исходник (сайт глючил).
И судя по отзывам автор не очень дружелюбен, и в место того чтобы обеспечить честность бенчмарков говорит «присылайте патчи» и сам их отвергает если они лично ему не нравятся.
Вообще сама идея делать такой сайт… Это всё равно что написать критичеси важную программу на 10 языках одновременно, которых сам не знаешь.
В случае критического бага отвечать «пришлите патч, сделайте форк» и ничего самому не делать.
Весь такой «продукт» можно отправлять в корзину, поэтому и патчи туда присылать даже не хочется.
В случае критического бага отвечать «пришлите патч, сделайте форк» и ничего самому не делать.
Весь такой «продукт» можно отправлять в корзину, поэтому и патчи туда присылать даже не хочется.
Синтетические тесты — ничто. Не устану этого повторять. Пиши код на том, что знаешь.
Я знаю и php, и Ruby, но вот на php возвращаться уже нет совершенно никакого желания. Единственное, что меня сейчас связывает с php — это предыдущие разработки, которые так или иначе надо совершенствовать… пока не найду время все это переписать на Ruby.
Я не сказал, что php — плох. Просто желания уже возвращаться к нему нет, пройденный этап.
Php вполне себе приличный язык. Про php я вообще упомянул вскольз.
Но то, что надо бы переписать во-первых слишком объемное, а во-вторых — текущих проектов на Руби достаточно для того, чтобы не было времени отвлекаться на что-то еще.
Php вполне себе приличный язык. Про php я вообще упомянул вскольз.
Но то, что надо бы переписать во-первых слишком объемное, а во-вторых — текущих проектов на Руби достаточно для того, чтобы не было времени отвлекаться на что-то еще.
да-да, просто кто-то из разряда «ниасилил» сказал, что это уже не модно и двинул туда, где попроще ;-)
Куда уж проще Руби?
Решаюсь улететь в минуса, но все же продолжу Вашу гениальную мысль…
А PHP-изм головного мозга — это…
варианты ответов не предлагаю.
Согласитесь, сколько холивара было начато именно на почве PHP.
А PHP-изм головного мозга — это…
варианты ответов не предлагаю.
Согласитесь, сколько холивара было начато именно на почве PHP.
Лично мой опыт, только мой — на написание сайта средней сложности на php у меня уходило 1.5 — 2 недели, на Ruby — 1 — 1.5.
И кода значительно меньше получается.
И кода значительно меньше получается.
1. Я не фрилансер
2. Я всегда стараюсь выполнить именно пожелания заказчика, потому как продукт пишется именно для него. Конечно, исключая случаи, когда требуется реализовать уж какой-то совершенно бред.
3. Преимущества сайта на Ruby, я думаю, будут очевидны даже заказчику.
Для заказчика прежде всего важны: соответствие проекта его пожеланиям, скорость исполнения проекта, надежность его работы, мне так кажется. А вот исполнителю как раз важно показать, что он сможет все это реализовать с помощью того инструмента, которым пользуется — в данном случае — система разработки, выбранная для реализации проекта. И желательно, чтобы потом не пришлось переписывать все на Go ;-)
2. Я всегда стараюсь выполнить именно пожелания заказчика, потому как продукт пишется именно для него. Конечно, исключая случаи, когда требуется реализовать уж какой-то совершенно бред.
3. Преимущества сайта на Ruby, я думаю, будут очевидны даже заказчику.
Для заказчика прежде всего важны: соответствие проекта его пожеланиям, скорость исполнения проекта, надежность его работы, мне так кажется. А вот исполнителю как раз важно показать, что он сможет все это реализовать с помощью того инструмента, которым пользуется — в данном случае — система разработки, выбранная для реализации проекта. И желательно, чтобы потом не пришлось переписывать все на Go ;-)
Кроме перечисленного для заказчика важна также легкость дальнейшей поддержки и быстрая замена в случае чего одного разработчика на другого. Найти хорошего пхп-программера, имхо проще чем просто рубиста.
Но тут не только пхп, есть ещё питон, который как мне кажется более популярен чем руби с рельсами, но имеет те же преимущества.
Но тут не только пхп, есть ещё питон, который как мне кажется более популярен чем руби с рельсами, но имеет те же преимущества.
Хороших разработчиков примерно везде одинаково, независимо от языка программирования. Тем более, тенденция последнего времени такова, что очень часто, начав с php, разработчики предпочитают сменить язык на Python или Ruby.
>Хороших разработчиков примерно везде одинаково, независимо от языка программирования.
То есть, на брейнфаке хороших программистов тоже самое количество, что и например, на сях?
То есть, на брейнфаке хороших программистов тоже самое количество, что и например, на сях?
Да, примерно одинаково. Именно хороших, а не всяких. И, как правило, первоклассные специалисты владеют несколькими языками программирования.
Я знаю (и имею опыт разработки) на Assembler, Pascal, C, C++, Delphi, C++ Builder, но для веб выбрал сначала Perl, потом PHP, сейчас Ruby.
И хочу сказать, что Ruby тем и хорош (ко всему прочему), что если заказчик нашел программиста на Ruby, то он с бОльшей уверенностью может предполагать, что это программист по крайней мере среднего уровня.
Это не голословные утверждения — мне доводилось сталкиваться с тем «кодом», который написал один деятель, закончивший 3-месячные курсы по PHP и считавший себя программистом. Контора до сих пор разгребает то дерьмо, что он понаписал. А я им сразу сказал, что в этом навозе я ковыряться не собираюсь — я не сантехник, мне гораздо проще было взять и написать все заново.
Я знаю (и имею опыт разработки) на Assembler, Pascal, C, C++, Delphi, C++ Builder, но для веб выбрал сначала Perl, потом PHP, сейчас Ruby.
И хочу сказать, что Ruby тем и хорош (ко всему прочему), что если заказчик нашел программиста на Ruby, то он с бОльшей уверенностью может предполагать, что это программист по крайней мере среднего уровня.
Это не голословные утверждения — мне доводилось сталкиваться с тем «кодом», который написал один деятель, закончивший 3-месячные курсы по PHP и считавший себя программистом. Контора до сих пор разгребает то дерьмо, что он понаписал. А я им сразу сказал, что в этом навозе я ковыряться не собираюсь — я не сантехник, мне гораздо проще было взять и написать все заново.
А откуда ещё плевки? Если можете, покидайте ссылочек.
А по теме, то кажется, всё в порядке: ребята быстро написали продукт на Rails, пришла пора масштабироваться — выбрали более подходящее решение.
Во-первых, не факт, что они не могли всё оптимально переписать на Ruby (например, используя другой фреймворк, активнее используя кеширование, переработав логику и т.п.). Во-вторых, даже, если и не могли, то, кажется, ничего страшного. У каждого языка\фреймворка должна быть своя ниша. Судя по тому, что их сервера перестали справляться Ruby\Rails прекрасно выполнили свою функцию.
А по теме, то кажется, всё в порядке: ребята быстро написали продукт на Rails, пришла пора масштабироваться — выбрали более подходящее решение.
Во-первых, не факт, что они не могли всё оптимально переписать на Ruby (например, используя другой фреймворк, активнее используя кеширование, переработав логику и т.п.). Во-вторых, даже, если и не могли, то, кажется, ничего страшного. У каждого языка\фреймворка должна быть своя ниша. Судя по тому, что их сервера перестали справляться Ruby\Rails прекрасно выполнили свою функцию.
Сейчас все больше склоняются к тому, что Ruby и Ruby on rails больше подходят для быстрой разработки прототипа. Написали, выкатили потестировали, переписали, потестировали и т.д. На больших нагрузках, как правило выбирают другое решение, либо комбинируют…
Так и есть.
Быстро написали — быстро выкатили — получили Proof of Concept — быстро нарастили клиентскую базу — у вас завелись деньги — нанимаете толпу инженеров и меняете платформу на более серьезную, если простая оптимизация узких мест не спасает.
Быстро написали — быстро выкатили — получили Proof of Concept — быстро нарастили клиентскую базу — у вас завелись деньги — нанимаете толпу инженеров и меняете платформу на более серьезную, если простая оптимизация узких мест не спасает.
гугол вот уже.давно использует питон для быстрого прототипирования, потом все на яву перегоняют.
Это совершенно не плевки в сторону Ruby. Ребята быстро написали прототип, выкатили в production, подняли на этом деньги и переписали сервис на инструменте, который к конкретно их задаче подходит лучше.
Ruby или Rails сами по себе не плохи, и там где надо, они справляются лучше всех. Но если какая-то компания отказалась от Rails в сторону чего-то быстрого, вероятно они просто адекватно оценивают задачи и подбирают инструменты. Не более, не менее.
Ruby или Rails сами по себе не плохи, и там где надо, они справляются лучше всех. Но если какая-то компания отказалась от Rails в сторону чего-то быстрого, вероятно они просто адекватно оценивают задачи и подбирают инструменты. Не более, не менее.
Ничего не случилось. Автор не говорит про ruby, он говорит про рельсы. А рельсы пишуться с идей «перформанс оставляем на потом, сейчас главное, чтобы всё было красиво».
We decided to rewrite the API. This was an easy decision
Мы решили переписать API. Это было непростое решение
Было бы интересно узнать подробнее — как выбирали язык. Интересно, почему отказались от erlang
Могу предположить, что переписывать с Ruby на Go всё-же проще, чем на Erlang. Проще в смысле проще переносить код 1 в 1. На Erlang/OTP придётся существенно перерабатывать.
Нынче уже есть elixir-lang.org/
перенос кода 1 в 1
Предположу существование еще одного важного фактора, действующего против Erlang — это отсутствие встроенных в язык словарей (aka dict, HashMap, map)
Предположу существование еще одного важного фактора, действующего против Erlang — это отсутствие встроенных в язык словарей (aka dict, HashMap, map)
Ruby достаточно быстр, дело больше в Rails – его разработчики никогда не чесались о производительности. Плюс если IronWorker спасла конкуррентность — скорее всего производительность упёрлась в GIL
GIL, как мне кажется, вообще всю идею конкурентности на корню убивает. Тогда уж проще на процессы разбивать все и не использовать нити вовсе.
Где там сказано что у них был один процесс? Не ужели бы они не заметили что только одно ядро используется?
GIL не позволяет потокам работать на разных ядрах, поэтому профиты от многопоточности сводятся почти к нулю. Из за GIL такие языки, как Ruby, Python, PHP, никогда не будут быстро работать в случае многопоточного программирования. Это ограничение by design, нужно или на процессы переходить, или на другие языки программирования.
В языке Python архитектурно нет никакого GIL, он есть в реализации CPython. В IronPython глобальных блокировок нет (мелкомягкие его поматросили и бросили, но он всё ещё рабочий). В Jython тоже такого анахронизма нет.
Подозреваю, аналогичная история с Ruby — не все реализации одинаково полезны.
Подозреваю, аналогичная история с Ruby — не все реализации одинаково полезны.
Большое спасибо за расказ о GIL.
Я как раз про то и говорю, что у них явно был не один процесс, а много. Соответсвенно GIL тут не причём.
Я как раз про то и говорю, что у них явно был не один процесс, а много. Соответсвенно GIL тут не причём.
В JRuby есть честные потоки, а в офф интерпретаторе уже ввели или почти ввели.
Думаю дело в тяжеловестности/оверхеде Rails и всяких других гемов.
Думаю дело вот в этой шляпе.
habrahabr.ru/post/84629/
habrahabr.ru/post/84629/
Смешная история. Если отбросить мусор, звучит она примерно так:
Мы решили сделать сервис под себя для агрегации данных.
В то время хиповыми трендами были Amazon-овские облака и Ruby, и мы выбрали их, потому что в Java нам обои надоели, а инструменты под задачу мы выбираем по принципу «это модно».
Когда сервис заработал, выяснилось, что производительность Ruby вообще никакая, хуже чем даже JS, сервера у Амазона очень дорогие, а архитектура нашего балансира нагрузки такова, что при первом же пике у него случается каскадный отказ серверов (это вообще шикарно!). Поскольку наш код конечно же был очень качественным, то мы решили, что во всем виноват Ruby!
Тогда мы решили подвигать кровати и сменить язык программирования, на ещё более экзотический GO.
Сначала мы боялись, что не сможем нанять крутых спецов по нему, но потому выяснилось, что даже крутые спецы по нему сидят без работы и прибежали к нам по первому зову. Среди них нашлись нормальные программеры, которые исправили нашу кривую архитектуру, и оказалось, что под нашу задачу с головой хватает 2 серверов. Вот такой волшенбый GO!
Короче, как в анекдоте. Ребята при составлении т.з. оперируют понятием «модные технологии» и думают, что отравились овсяным печеньем.
Мы решили сделать сервис под себя для агрегации данных.
В то время хиповыми трендами были Amazon-овские облака и Ruby, и мы выбрали их, потому что в Java нам обои надоели, а инструменты под задачу мы выбираем по принципу «это модно».
Когда сервис заработал, выяснилось, что производительность Ruby вообще никакая, хуже чем даже JS, сервера у Амазона очень дорогие, а архитектура нашего балансира нагрузки такова, что при первом же пике у него случается каскадный отказ серверов (это вообще шикарно!). Поскольку наш код конечно же был очень качественным, то мы решили, что во всем виноват Ruby!
Тогда мы решили подвигать кровати и сменить язык программирования, на ещё более экзотический GO.
Сначала мы боялись, что не сможем нанять крутых спецов по нему, но потому выяснилось, что даже крутые спецы по нему сидят без работы и прибежали к нам по первому зову. Среди них нашлись нормальные программеры, которые исправили нашу кривую архитектуру, и оказалось, что под нашу задачу с головой хватает 2 серверов. Вот такой волшенбый GO!
Короче, как в анекдоте. Ребята при составлении т.з. оперируют понятием «модные технологии» и думают, что отравились овсяным печеньем.
Справедливости ради речь шла о недостатках масштабируемости RoR, а не Ruby, и выбирали скриптовый язык (для задач iron.io, наверное, имеет смысл). Хотя, конечно, дело навряд ли было в переходе на Go.
модные технологии это достаточно важный критерий, для некоторых, хотя я тоже с ним не согласен
По правде говоря, производительность кода зависит в первую очередь от компилятора, потом от программиста потом от железа!!!
Если железо не тянет меняем железо, если код тормознутый меняем код, если код не тянет меняем компилятор.
Только вот жаль что еще нету одного пункта «Поменять МОЗГИ»
Может быть они имели виду что GO создавался компанией ГУГЛ как раз для больших нагрузок ??
Ведь не секрет что сервера гугл тоже падают!!!
Если железо не тянет меняем железо, если код тормознутый меняем код, если код не тянет меняем компилятор.
Только вот жаль что еще нету одного пункта «Поменять МОЗГИ»
Может быть они имели виду что GO создавался компанией ГУГЛ как раз для больших нагрузок ??
Ведь не секрет что сервера гугл тоже падают!!!
Как вы тут оказались, если не секрет?
По правде говоря, производительность кода зависит в первую очередь от компилятора, потом от программиста потом от железа!!!
В теме элитный специалист в области компиляторостроения, все в
А программисты не нужны, вот.
Спасибо комрад, вы написали то что я хотел. У меня вообще всегда ощущение от таких вот кейсов (уже второй на моей памяти) очень печальное.
Я CTO и я выбираю технологии исключительно с подхода моды. Я сделал первую версию весьма плохой. Но не могу же я признать, что взял совершенно не верные инструменты в виде rails? Может быть мне стоит не тратить деньги фирмы. не выбрасывать наработки и опыт людей? может стоит оставить все на руби, но переписать на EventMachine или fibers. Может хотя бы провести тесты..? эмммм, неееет, лучше перепишем все на новом модном языке. И чудо, чудо правильно выбраная парадигма жрет разумное количество ресурсов. Стоит ли теперь признать, что я некомпетентен? эммм, неее, лучше обвиню неверно мной выбранный инструмент.
В прошлый раз, тоже ктото из Linked рассказывал, как он заменили синхронный rails на асинхронный node.js для чата (или чего то подобного) и тоже как дети радовались что заработало быстрее.
Ну тут же все взрослые люди, прирост производительности в 15 раз, только за счет языка? верится с трудом. Сложно судить не зная задачи, но почти уверен, что перепиши они задачу на fibers, нууу 4 бы сервера использовали. Зато сколько денег на разработке бы сэкономили.
Я CTO и я выбираю технологии исключительно с подхода моды. Я сделал первую версию весьма плохой. Но не могу же я признать, что взял совершенно не верные инструменты в виде rails? Может быть мне стоит не тратить деньги фирмы. не выбрасывать наработки и опыт людей? может стоит оставить все на руби, но переписать на EventMachine или fibers. Может хотя бы провести тесты..? эмммм, неееет, лучше перепишем все на новом модном языке. И чудо, чудо правильно выбраная парадигма жрет разумное количество ресурсов. Стоит ли теперь признать, что я некомпетентен? эммм, неее, лучше обвиню неверно мной выбранный инструмент.
В прошлый раз, тоже ктото из Linked рассказывал, как он заменили синхронный rails на асинхронный node.js для чата (или чего то подобного) и тоже как дети радовались что заработало быстрее.
Ну тут же все взрослые люди, прирост производительности в 15 раз, только за счет языка? верится с трудом. Сложно судить не зная задачи, но почти уверен, что перепиши они задачу на fibers, нууу 4 бы сервера использовали. Зато сколько денег на разработке бы сэкономили.
С другой стороны веб-приложения с претензией на динамичное развитие написанные на Java доставляют. Правда проблем разработчикам, которые не успевают угнаться за рынком.
Почему Вы решили что дело в модели многопоточности? Да ruby код не в вакуме живёт. Использует библиотеки, гемы, решающие всякие практические задачи, которые тоже могу влиять на производительность.
Основная проблема, что статья скорее вброс чем источник информации. Любой компетентный человек сделал бы две вещи:
1)Хотя бы _попробовал_ бы пофиксить архитектуру на текущей платформе. Ну чисто изза экономических соображений.
2) Произвел бы хотя бы минимальные бенчмарки на каком то подмножестве своей задачи и получил бы конкретные _цифры_
Оперирование фактами и цифрами, вот что отличает компетентного инжинера, от фанбоев. Если автор не приводит все эти «несущественные детали», то конечно можно предполагать что он все это делал… но известная бритва требует признать, что скорее все намного проще и это просто не делалось.
В целом, следуя собственной логике, я считаю обсуждать тут нечего — ни фактов, не цифр в статье нет. Как оно там было на самом деле, можно только предполагать.
1)Хотя бы _попробовал_ бы пофиксить архитектуру на текущей платформе. Ну чисто изза экономических соображений.
2) Произвел бы хотя бы минимальные бенчмарки на каком то подмножестве своей задачи и получил бы конкретные _цифры_
Оперирование фактами и цифрами, вот что отличает компетентного инжинера, от фанбоев. Если автор не приводит все эти «несущественные детали», то конечно можно предполагать что он все это делал… но известная бритва требует признать, что скорее все намного проще и это просто не делалось.
В целом, следуя собственной логике, я считаю обсуждать тут нечего — ни фактов, не цифр в статье нет. Как оно там было на самом деле, можно только предполагать.
Вообще-то, производительность легко может вырости в несколько раз только за счет использования другого компилятора. Например, по этой ссылке в последней таблице некоторые программы, скомпилированные Intel C++ Compiler, в 3 раза быстрее, чем скомпилированные GCC (да, это не 15 раз, но тем не менее).
Да как же с этим поспоришь, от оптимизатора много зависти. Я понимаю разницу между интерпретируем Ruby и компилируемым go. И собственно на счет скорости ruby иллюзий в принципе не имею. :)
Но уважаемые комрады… увеличение производительности в 30 раз (он пишет что второй сервер для резерва и в комменте выше я это не учел) просто за счет смены языка. Я верю в это с трудом. Скорее всего все же были и какие то архитектурные изменения которые позволили такого добиться.
Но уважаемые комрады… увеличение производительности в 30 раз (он пишет что второй сервер для резерва и в комменте выше я это не учел) просто за счет смены языка. Я верю в это с трудом. Скорее всего все же были и какие то архитектурные изменения которые позволили такого добиться.
В go нет особо развесистых фреймворков, в которых чтобы добраться до целевой части нужно выполнить тыщу и одно действие. Плюс, все что нужно можно пустить асинхронно через go. Так что не чего там удивительного нет. Менять скорей пришлось не архитектуру, а структуру кода, что как бы и так понятно…
Ну а в rails к руби гвоздями что ли прибит? Что мешало убрать его. Легковесных фремворков в руби достаточно. Включая асинхронные.
И вынужден с вами не согласится — переход на асинхронную парадигму, это архитектурное решение. Иначе вообще любые изменения в приложение, можно было описать как «изменение структуры кода». Что в целом конечно правда, но слишком широкое определение что бы было полезным.
мое имхо, что статья должна называться «как мы переписали код используя асинхронный подход (ну и кстати перешли на go) и уменьшили потребляемые ресурсы».
И вынужден с вами не согласится — переход на асинхронную парадигму, это архитектурное решение. Иначе вообще любые изменения в приложение, можно было описать как «изменение структуры кода». Что в целом конечно правда, но слишком широкое определение что бы было полезным.
мое имхо, что статья должна называться «как мы переписали код используя асинхронный подход (ну и кстати перешли на go) и уменьшили потребляемые ресурсы».
Как-то раз (для выбора на чем писать) на Python 2.7 измерял скорость цикла с небольшими арифметическими выражениями (сложение, умножение, деление). Потом сделал тот же цикл на делфи. Скорость была почти в 100 раз больше. Далее сделал библиотеку с этим же циклом на Cython'е и вызывал функцию из питоновского скрипта. Таким образом увеличил скорость выполнения скрипта в 20 раз. А Вы говорите в 30 раз не может…
Это синтетические числодробильные тесты. В реальной жизни всё упирается в работу с БД или в работу с памятью.
Ну тут же все взрослые люди, прирост производительности в 15 раз, только за счет языка? верится с трудом.
Очень даже может быть, однако go как раз-таки и создавался для написания сильно нагруженных веб-сервисов.
И то, что ruby — это «вечный тормоз прогресса», тоже ни для кого не секрет, интерпретируемый язык с динамической типизацией. Тогда как go — компилируемый язык со статической типизацией. Поправьте меня, если я не прав. Вот если бы увидеть реальный бенчмарк сравнения двух языков, тогда было бы о чем говорить, а так — сплошные догадки.
поправляю: со строгой динамической типизацией
У Go — статическая типизация. Программы на этом языке получаются очень шустрыми, такой язык, как Ruby, легко может слить Go по скорости в 10 и более раз. Советую всем (программистам, которых интересует данная тема) прочитать откровения Роба Пайка от том, как, для чего, и каким образом создавался этот язык и его компилятор. Многие вопросы отпадут.
p.s.: здесь неплохо написано про Go: хабрастатья
p.s.: здесь неплохо написано про Go: хабрастатья
у руби ведь есть jit тоже…
Скролил вниз в поисках такого камента. Сам руби разработчик, но для агрегации данных никогда бы не вырал руби.
Спасибо, Вы очень подняли мне настроение с утра своим комментарием! :)
Я конечно понимаю что целью было максимальное передергивание и гипербола, но все же
Вы правда думаете что есть крутые спецы, которые знают Go и только его?
Вы правда думаете что перспектива работать (а не только писать для себя) на языке, который тебе больше по душе — это не аргумент?
У ребят все отлично :) Они написали штуку на RoR, которая быстро стала популярной, появилась проблема с производительностью, переписали (язык имхо вообще не ключевой фактор, хотя Go в их случае — хороший выбор), тем самым избавились от проблемы. Классика.
Сначала мы боялись, что не сможем нанять крутых спецов по нему, но потому выяснилось, что даже крутые спецы по нему сидят без работы и прибежали к нам по первому зову.
Вы правда думаете что есть крутые спецы, которые знают Go и только его?
Вы правда думаете что перспектива работать (а не только писать для себя) на языке, который тебе больше по душе — это не аргумент?
Короче, как в анекдоте. Ребята при составлении т.з. оперируют понятием «модные технологии» и думают, что отравились овсяным печеньем.
У ребят все отлично :) Они написали штуку на RoR, которая быстро стала популярной, появилась проблема с производительностью, переписали (язык имхо вообще не ключевой фактор, хотя Go в их случае — хороший выбор), тем самым избавились от проблемы. Классика.
отлично сформулировано! меняем в статье GO на Scala, Clojure или Erlang и смысловая нагрузка не изменится. Абсолютно анекдотичные выводы
может Ruby и не самый быстрый, но при определённой правильности рук легко можно добится хороших результатов.
с масштабируемостью тоже всё в порядке — habrahabr.ru/post/170033/
просто надо выбирать инструменты используя мозг а не стадный инстинкт…
с масштабируемостью тоже всё в порядке — habrahabr.ru/post/170033/
просто надо выбирать инструменты используя мозг а не стадный инстинкт…
так и знал что любителей поездов заденет и станут беспощадно минусовать :)
устал повторять… 150-200 зпс обрабатываются в то время как держатся подключёнными миллион клиентов!
при 100к подключённых клиентов обрабатываются 4к запросов в секунду — raw.github.com/slivu/1mc2/master/results/requests-per-second.png
и это чисто лабораторный тест призванный доказать что Ruby решения таки можно масштабировать, а не то что он может быстро обрабатывать запросы.
при 100к подключённых клиентов обрабатываются 4к запросов в секунду — raw.github.com/slivu/1mc2/master/results/requests-per-second.png
и это чисто лабораторный тест призванный доказать что Ruby решения таки можно масштабировать, а не то что он может быстро обрабатывать запросы.
В общем то неплохо, но хотелось бы более конкретных примеров. Например, что так тормозило в руби/рейлс: память, робота с сетью, кривая архитектура, насколько стало сложнее/проще саппортить проект. Просто вода.
А чем к примеру Go лучше Python+Gevent?
Их не поддерживает Google, да и названия длинные, не модные.
это зависит от компилятора и интерпретатора. Сам интерфейс языка и его возможности от этого никак не заыисят. А интересует именно разница между возможностями. Я часто в работе использовал Gevent и это наверно самый лучший и удобный фрейм для Python. Вопрос в том что такого может предложить Go. Тем более учитывая что язык новый, то либ для него довольно мало а это накладывает дополнительное время на разработку.
Вопрос в том что такого может предложить Go.
В Golang возможности фреймворка Gevent заложены в дизайн самого языка.
это зависит от компилятора и интерпретатора
Интерпретируемый динамически типизированный (python) VS. компилируемый статически типизированный (golang). Более высокая скорость работы первого возможна только при повышенной криворукости разработчиков компилятора второго.
Очень не факт, коечто еще зависит от архитектуры, ибо архитектура всегда накладывает свои ограничения.
Ну судя по тестам, разработчики там достаточно криворукие + небольшое комьюните. А для Python к примеру есть модуль в составе boost для написания библиотек на Си++, что довольно просто позволяет обрезать узкие места с которыми несправляется сам Python. К тому же есть еще Pyrex.
Судя по всему этому я реально не вижу какогото выиграша. Посему вот интересно, почему выбрали именно Go, что на это побудило, и что в итоге они поняли после того как написали на нем сервис.
Ну судя по тестам, разработчики там достаточно криворукие + небольшое комьюните. А для Python к примеру есть модуль в составе boost для написания библиотек на Си++, что довольно просто позволяет обрезать узкие места с которыми несправляется сам Python. К тому же есть еще Pyrex.
Судя по всему этому я реально не вижу какогото выиграша. Посему вот интересно, почему выбрали именно Go, что на это побудило, и что в итоге они поняли после того как написали на нем сервис.
коечто еще зависит от архитектуры, ибо архитектура всегда накладывает свои ограничения
Архитектуры чего?
Ну судя по тестам, разработчики там достаточно криворукие
Benchmark-и в студию тогда. Судя по public тестам — вполне себе адекватные.
А для Python к примеру есть модуль в составе boost для написания библиотек на Си++
Разговор сейчас о Python/Go, а не о C++. Писать модули для Python на C/C++ — занятие достаточно геморное (повторять этот опыт уж точно не хочется).
Судя по всему этому я реально не вижу какогото выиграша
«все это» — это «достаточно криворукие» разработчики в google и «модуль в составе boost»? Необычный подход к выбору технологии.
Равнять с питоном 3м смысла нет, юзают по сути 2.6-2.7.
Тесты на математическую производительность логично что будут в пользу Go. А вот тесты на парсинг джейсона, на работу сервера, чтение файлов… собственно то что в основном используется во всех языках были бы куда интересней. В нете особо четких тестов нет, есть тока куски разные но народ говорит не в пользу Go.
Вот какой то тест по сервакам http://ziutek.github.com/web_bench/. Там нет чистого Gevent. посему скажу что по тестам между питоновскими серваками gevent тянет вдвое больше чем Tornado, что больше Go http
Тесты на математическую производительность логично что будут в пользу Go. А вот тесты на парсинг джейсона, на работу сервера, чтение файлов… собственно то что в основном используется во всех языках были бы куда интересней. В нете особо четких тестов нет, есть тока куски разные но народ говорит не в пользу Go.
Вот какой то тест по сервакам http://ziutek.github.com/web_bench/. Там нет чистого Gevent. посему скажу что по тестам между питоновскими серваками gevent тянет вдвое больше чем Tornado, что больше Go http
При прочих равных — это всегда факт.
Единственное, чем могут быть лучше интерпретируемые, динамические, скриптовые языки — это скорость разработки приложений, где эффективность использования процессорного времени является несущественным критерием.
Когда нужно было быстро и эффективно разрабатывать и развивать приложение, ребята использовали Ruby/RoR. Когда архитектура стабилизировалась и объем обрабатываемых данных начал расти, пришло время оптимизации скорости.
Это абсолютно нормально. Это стандартный этап жизненного цикла высоконагруженных приложений.
Некоторые на этом этапе начинают переписывать критичные места систем на Си, а то вообще на Assembler. Это приводит к серьезному усложнению. Появляется зоопарк используемых инструментов. Систему становится сложно сопровождать из-за этого. Типовая проблема…
Эти ребята решили вопрос кардинально. Переписали на Go. И в своём конкретном случае не прогадали.
Вовсе факт, что для других проектов переписать на Go будет правильным решением и даст такой же результат. Просто ребята обращают внимание тех, кто еще не разучился думать, что есть такой вариант решения проблемы. Что выбрать — это уже ваше решение.
А RoR — с ним всё в порядке. Он в случае этих ребят успешно выполнил свою работу. Мавр сделал своё дело, мавр может уходить…
Единственное, чем могут быть лучше интерпретируемые, динамические, скриптовые языки — это скорость разработки приложений, где эффективность использования процессорного времени является несущественным критерием.
Когда нужно было быстро и эффективно разрабатывать и развивать приложение, ребята использовали Ruby/RoR. Когда архитектура стабилизировалась и объем обрабатываемых данных начал расти, пришло время оптимизации скорости.
Это абсолютно нормально. Это стандартный этап жизненного цикла высоконагруженных приложений.
Некоторые на этом этапе начинают переписывать критичные места систем на Си, а то вообще на Assembler. Это приводит к серьезному усложнению. Появляется зоопарк используемых инструментов. Систему становится сложно сопровождать из-за этого. Типовая проблема…
Эти ребята решили вопрос кардинально. Переписали на Go. И в своём конкретном случае не прогадали.
Вовсе факт, что для других проектов переписать на Go будет правильным решением и даст такой же результат. Просто ребята обращают внимание тех, кто еще не разучился думать, что есть такой вариант решения проблемы. Что выбрать — это уже ваше решение.
А RoR — с ним всё в порядке. Он в случае этих ребят успешно выполнил свою работу. Мавр сделал своё дело, мавр может уходить…
я помню на бейсике писал успешные проекты, но это не причина говорить что он хорош. Мне по этому и интересно сравнение Go и Python. Итнересно узнать глубинную разницу от людей которые положили на этот язык толпу юзеров. И есть ли большая разница в итоге между этими двумя языками. Ибо если нет, то комьюнити решает.
Раз проекты были успешные, значит бейсик был хорош для вас, для вашего уровня знаний тогда… Это самый объективный критерий. Тот самый случай, когда победителей не судят…
И есть ли большая разница в итоге между этими двумя языками.
Между этими языками просто катастрофическая разница. И помимо очевидного (python / go):
динамически типизированный / статически типизированный
интерпретируемый / компилируемый
ооп / «не-опп»
(а это уже очень большая разница), golang по дизайну предначначен для написания concurrent кода с последующей параллелизацией выполнения. Последнее различие фундаментально и изначально ставит языки по разным углам. При таком количестве различий — сравнивать языки без привязки к задаче — не имеет никакого смысла. Python с Ruby можно сравнивать без контекста — потому что там общих черт больше, чем различий. А Golang намного ближе к Erlang — тут сравнение было бы конструктивным.
P.S. Предвидя возможный возражения, скажу сразу — задача «написать сервер» слишком общая. А если уже сравнивать с gevent-ом, то event-based concurrency внутри одного thread-a всегда будет уступать возможностям собственного планировщика с возможностью работать на нескольких ядрах.
Чем вам Гоу не ООП?
Нет иерархии типов (и наследования, естественно). Вот этот пункт из FAQ и некоторые последующие.
Я хорошо знаю Гоу, спасибо.
Не понимаю только почему нет наследования, я вполне могу включить один struct в другой у получить у последнего всё что есть (публичного) у родительского.
Не понимаю только почему нет наследования, я вполне могу включить один struct в другой у получить у последнего всё что есть (публичного) у родительского.
Естественно, вы можете и на C писать, выкручивая себе руки и голову так, чтобы воссоздать функционал классов и наследования там, где создатели языка его не предполагали. Только язык не будет помогать вам это делать, ибо у него другая семантика. Как говорится «на Pascal-e можно писать на любом императивном языке», так и «ооп можно всунуть в любом императивный язык, были бы структуры». Это не делает дизайн языка хоть сколько-нибудь ООП-шным.
Всё верно, только к Гоу это не относится. Расширение сктруктур это не костыли, это так задумано.
В Go нет наследования, и это хорошо :)
В Go есть duck-typing при статической типизации — и это просто волшебно.
«инкапсуляция, наследование, полиморфизм» (tm) :)
Инкапсуляция есть, наследования нет, полиморфизм есть
еще есть интерфейсы, duck-typing и расширение структур
вполне себе ООП, просто не Java
В Go есть duck-typing при статической типизации — и это просто волшебно.
«инкапсуляция, наследование, полиморфизм» (tm) :)
Инкапсуляция есть, наследования нет, полиморфизм есть
еще есть интерфейсы, duck-typing и расширение структур
вполне себе ООП, просто не Java
Тот же комментарий, что и выше. Я и не говорил, что это плохо. ООП без наследования теряет свою суть чуть более чем полностью. Инкапсуляция и полиморфизм касаются других парадигм не в меньшей степени (а иногда и в большей), чем ООП.
Почему наследования-то нет? Есть же.
А Golang намного ближе к Erlang — тут сравнение было бы конструктивным.Да ладно ближе… Ваще разные.
Erlang это FP, изолированные процессы-акторы, интерпретируемый, динамическая типизация. Go-императивный, зеленые потоки (как понимаю — не изолированные), нативный код, статическая типизация.
И там и там — изолированные. И там и там — с собственным scheduler-ом(ами). И там и там общение через обмен сообщениями (только механизмы адресации сообщений разные). Общий подход к обеспечению concurrency — это серьезная overlap между языками — гораздо больший, чем между go и ruby.
Если в 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}
у python есть компиляция и есть вариант со статической типизацией (для ценителей). На удивление — это мало влияет на производительность в общем случае. Для того, чтобы ускорить код, переключившись на статическую типизацию, нужно заметно улучшить качество кода. Как показывает опыт — оплатить труд программистов, которые напишут код качественно — значительно дроже, чем оплатить еще N+X серверов. Это правило работает до определенных пределов, так как масштабирование «в лоб» не работает почти никогда, рост производительности растет обычно по обратной геометрической функции. Просто большинство кодовых инсталляций не доживает до того, как начинаются проблемы с масштабирование.
Вы не правы. Динамические языки прекрасто справляются со своими динамическими проблемами благодарю JIT'у. Другое дело, что статические компилируемые языки можно сразу оптимизировать, а JIT'у надо дать время прогреться.
Вот тут автор прекрасно это объясняет: speakerdeck.com/alex/why-python-ruby-and-javascript-are-slow
Вот тут автор прекрасно это объясняет: speakerdeck.com/alex/why-python-ruby-and-javascript-are-slow
Python
python yourfile.py
и в результате файл с байт кодом, который не слишком отстает от java
python yourfile.py
и в результате файл с байт кодом, который не слишком отстает от java
Беглое сравнение производительности go и питона показывают не самые впечатляющие результаты. Парсер json и движок регулярных выражений оказались медленнее встроенных питоновских (не говоря уже об ujson). А еще не забываем об pypy.
Отсутствием GIL? Наличием многопоточности, которая приносит реальные профиты. Статической типизацией, которая ловит ошибки на этапе компиляции, а не во время исполнения.
Руби, Пизон, Го, хостинг Амазона, Нода.джс… Все пройдет, а ПХП останется =)
Мне интересно, если бы они отказались только от рельсов, а написали бы все на чистом руби, какой прирост это дало бы?
А почему не использовали sinatra? Он наверняка больше подходит под написание api.
как бы там не было — frontend у них остался на Rails (при этом не самые новые Rails).
Чем то похоже на эту тему 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/
Ну на самом деле они просто выбрали неправильный инструмент. Если нужна производительность то нужно использовать сервера с неблокирующим 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/
3 года назад ни целулоидов ни голиафоф не было а если и были то в зачаточном состоянии. Мне кажется для них все получилось нормально. Код стал устаревать и его зарефакторили просто на другом языке, а это значит устранили узкие места, которые могли быть не видны в начале проекта.
А мне тоже Go понравился. Я понимаю, что сообщество маленькое, что бибилотек маловат (я в курсе что судя по списку есть все и даже больше, но это все слабо поддерживается и судя по звездам мало кому нужно) и это огорчает. Язык судя по всему большинство пытается использовать в web-разработке, и создателям крайне необходимо взять все требуемые либы под свое крыло, иначе с уверенностью будет туговато.
Сообщество маленькое, но крепкое. В #go-nuts на irc.freenode.net всегда помогут по любым вопросам.
Оно конечно так, ну либ мало, а то что есть особо не поддерживается и создателей тут даже винить не стоит, судя по репам не сильно много нуждается в них. По этому когда думаешь может что-нибудь написать, а потом понимаешь, а кому оно надо будет. Кроме того есть канторы, которые заявляют что «мы используем», но выкладывать свои наработки они не хотят, возможно по тем же причинам, а возможно выкладывать особо не чего.
Хотелось бы услышать больше о том чем плох java. Я не пишу на нем, просто интересно
Не модно использовать Java, вот Go, node.js, RoR, другое дело.
долгая перкомпиляция фиксится компьютером по-мощнее :)
p.s. пишу на java от заката до рассвета и наоборот и не использую тяжеловесную ненужную требуху типа WebSphere и Weblogic, чувствуя себя с ней довольно комфортно и не испытываю каких-то проблем со скоростью разработки.
p.s. пишу на java от заката до рассвета и наоборот и не использую тяжеловесную ненужную требуху типа WebSphere и Weblogic, чувствуя себя с ней довольно комфортно и не испытываю каких-то проблем со скоростью разработки.
Быстрый цикл разработки не гарантирует быстрого выпуска продукта
Я писал на PHP какое-то время назад и в начале действительно проще и быстрее. Но это начало длится очень недолго. Какой-то серьезный проект я бы не стал писать на PHP/Ruby/Python. Это связано с тем, что потом поддерживать эту систему будет адски сложно когда она разрастется. Хотя нет, если бы это был проект «на выброс» из одной странички, то может и стал бы.
А проект по типу интернет магазина уже не стал бы.
Скорость разработки это не только скорость того, как скоро увидишь свои изменения после изменения в коде, но и то, как эффективно ты сможешь поддерживать код и то, как быстро ты сможешь заделиверить фичи и то, как быстро ты сможешь выполнить требование о том, какую нагрузку твоя веб-аппликация/веб-сервис должен тянуть.
А проект по типу интернет магазина уже не стал бы.
Скорость разработки это не только скорость того, как скоро увидишь свои изменения после изменения в коде, но и то, как эффективно ты сможешь поддерживать код и то, как быстро ты сможешь заделиверить фичи и то, как быстро ты сможешь выполнить требование о том, какую нагрузку твоя веб-аппликация/веб-сервис должен тянуть.
А на чем бы Вы, например, уже интернет магазин реализовали бы, позвольте поинтересоваться? Я так понимаю, что PHP/Ruby/Python Вы не рассматриваете для реализации таких сложных проектов?
На Java любимой.
Если интересует чуть глубже, то:
Контейнер Tomcat или Jetty, для веб-морды Spring MVC или Struts 2, персистенс — Hibernate или MyBatis или Spring JDBC.
На требования нужно смотреть что бы сказать точнее в пользу чего склонился бы.
Если интересует чуть глубже, то:
Контейнер Tomcat или Jetty, для веб-морды Spring MVC или Struts 2, персистенс — Hibernate или MyBatis или Spring JDBC.
На требования нужно смотреть что бы сказать точнее в пользу чего склонился бы.
Наверное это нечто волшебное, по сравнению с PHP/Ruby/Python… наверное код на Java волшебным образом не разрастается (цитата: «потом поддерживать эту систему будет адски сложно когда она разрастется»).
Всегда предполагал, что все-таки качество кода и способность его дальнейшего сопровождения в очень большей степени зависит от разработчика. Ан нет, оказывается есть еще чудеса на свете!
Всегда предполагал, что все-таки качество кода и способность его дальнейшего сопровождения в очень большей степени зависит от разработчика. Ан нет, оказывается есть еще чудеса на свете!
Код как раз разрастается.
Для меня лично при увеличении кодовой базы, то что творится в коде на Java/[другом языке со статической типизацией] понимать легче, чем то, что творится с кодом с динамической типизацией. Легче допиливать новые фичи и фиксить баги.
А теперь представьте себе поддержку интернет банка который написан на PHP и сменилось несколько поколений разработчиков. И код там разного качества. Как легко и просто это будет поддерживать?
И вам нужно впихнуть какой-то новый функционал. У вас есть пару десятков разрозненных модулей и вам нужно удалить часть старой фунциональностей и заменить на новый. Если мой проект на Java, то у меня что-то просто нескопмилируется где-то и я узнаю об этом раньше, чем это выйдет на продакшн(в общем случае, если не использовать Reflection, за необоснованное использование которого нужно люлей вставлять).
Я полностью согласен с тем, что качество кода зависит от девелопера.
Я говорю немного о другом. О том что после того, как проект пересекает какую-то черту по фичам/размеру кодовой базы, сложность дальнейшей его поддержки и внедрения новых фич на Python/Ruby/PHP становится на порядки сложнее, чем на Java/[другом языке со статической типизацией].
Для меня лично при увеличении кодовой базы, то что творится в коде на Java/[другом языке со статической типизацией] понимать легче, чем то, что творится с кодом с динамической типизацией. Легче допиливать новые фичи и фиксить баги.
А теперь представьте себе поддержку интернет банка который написан на PHP и сменилось несколько поколений разработчиков. И код там разного качества. Как легко и просто это будет поддерживать?
И вам нужно впихнуть какой-то новый функционал. У вас есть пару десятков разрозненных модулей и вам нужно удалить часть старой фунциональностей и заменить на новый. Если мой проект на Java, то у меня что-то просто нескопмилируется где-то и я узнаю об этом раньше, чем это выйдет на продакшн(в общем случае, если не использовать Reflection, за необоснованное использование которого нужно люлей вставлять).
Я полностью согласен с тем, что качество кода зависит от девелопера.
Я говорю немного о другом. О том что после того, как проект пересекает какую-то черту по фичам/размеру кодовой базы, сложность дальнейшей его поддержки и внедрения новых фич на Python/Ruby/PHP становится на порядки сложнее, чем на Java/[другом языке со статической типизацией].
Уповать только на то, что компилятор что-то не пропустит? Довольно сомнительно. Гораздо чаще дело не в типах, а в стиле написания кода (трудность для дальнейшего сопровождения) и все-таки в логике работы приложения.
Могу точно так же перефразировать: «А теперь представьте себе поддержку интернет банка который написан на Java и сменилось несколько поколений разработчиков. И код там разного качества. Как легко и просто это будет поддерживать?». Ключевое тут: «сменилось несколько поколений разработчиков» и «код там разного качества».
Могу точно так же перефразировать: «А теперь представьте себе поддержку интернет банка который написан на Java и сменилось несколько поколений разработчиков. И код там разного качества. Как легко и просто это будет поддерживать?». Ключевое тут: «сменилось несколько поколений разработчиков» и «код там разного качества».
Между уповать и иметь гарантию огромная пропасть ;)
Интернет банков на PHP написанных слава богу я не видел. На Java видел и жить с этим можно.
Интернет банков на PHP написанных слава богу я не видел. На Java видел и жить с этим можно.
Вы действительно считаете, что строгая типизация гарантирует Вам корректность работы программ?
Дальше, в принципе, можно не продолжать диалог. Спасибо за содержательные ответы.
Дальше, в принципе, можно не продолжать диалог. Спасибо за содержательные ответы.
Ничто не гарантирует ничего. Строгая типизация ПОМОГАЕТ. Не более.
Согласен. Слабая типизация языка требует от разработчиков более высокой культуры кодирования, если хотите (следование разработанным conventions, coding standards и тп). В противном случае получится неструктурированная каша.
Правда, из этого следует, что строгая типизация помогает сохранять структуру приложения (что важно для поддержки кодовой базы), но не гарантирует корректность.
Правда, из этого следует, что строгая типизация помогает сохранять структуру приложения (что важно для поддержки кодовой базы), но не гарантирует корректность.
пишу на java от заката до рассвета
Вот! А писали бы не на Java, еще и время на сон оставалось бы.
Java — это не только и не столько язык, сколько платформа: JVM, библиотеки, фреймворки, сборщики, продукты, etc. И это дерьмо постоянно растет, но нисколько не совершенствуется. И проблема в том, что сейчас на голой джаве уже практиески никто не пишет. Все современные архитектурные шаблоны на java ведут к наворачиванию технологий распуханию аппликации. Вот пример для простой вебапликации: JBoss+SpringMVC+EJB+JPA+JSP+Maven+Arquillian. И это не предел. Естественно что разработка со всем этим дерьмом будет еле ворочаться. Но тем не менее, сама компиляция в Java очень быстрая.
P.S. Хочется писать лаконичнее — возьмите к примеру Groovy, XTend или Kotlin.
P.S. Хочется писать лаконичнее — возьмите к примеру Groovy, XTend или Kotlin.
Далеко не в каждое приложении на Java нужно тащить половину JaveEE стека.
Насчет «будет еле ворочаться» можно вспомнить пример «быстрой» hypertable на C++, которая в отличии от «медленной» HBase не только медленнее, но и не работает почти)
Насчет «будет еле ворочаться» можно вспомнить пример «быстрой» hypertable на C++, которая в отличии от «медленной» HBase не только медленнее, но и не работает почти)
Если держать себя в руках, то все хорошо: можно без проблем использовать чистую джаву и playframework, например.
Ну не все дерьмо. Можно и не использовать JBoss, EJB, Arquillian и прочую энтерпрайз money hungry херню когда это не нужно.
Можно стек и упростить. Многие приложений не неуждаются в полноценном Апп Сервере с поддердкой J2EE, хватает тех фичей что предоставляют сервлет контейнеры Jetty/Tomcat. Да и по сути по мере надобности можно тот же JMS etc прикрутить к Jetty/Tomcat'у.
P.S. Scala тоже очень ничего.
Можно стек и упростить. Многие приложений не неуждаются в полноценном Апп Сервере с поддердкой J2EE, хватает тех фичей что предоставляют сервлет контейнеры Jetty/Tomcat. Да и по сути по мере надобности можно тот же JMS etc прикрутить к Jetty/Tomcat'у.
P.S. Scala тоже очень ничего.
Что ж вы там компилируете такое? Мой проект с 5k классами полностью компилится за 8 секунд.
долгая перекомпиляция тоже не радуетМне всегда казалось, что компилятор java очень быстрый (особенно, по сравнению с c/c++). Ведь он не требует повторных запусков, самостоятельно разрешая зависимости на уровне кода и кешируя информацию о уже скомпилированных классах. Думаю, большую часть сборки вашего приложения занимает maven и многократная архивация, ведь java-инфраструктура использует архивы в архивах.
К примеру, собирал как-то java-порт BerkelyDB. В нём около тысячи классов, а ant собрал всё на моей не особо мощной машине за ~11 сек.
Вопрос слишком общий, все зависит от конкретной задачи
Java ничем не плоха. Просто некоторые не умеют ее готовить.
А вы действительно переписали API — Application programming interface? Или всё таки его реализацию?
C++
Что может быть лучше классики?
Что может быть лучше классики?
«Чем бы дети не баловались, лишь бы новые языки не писали.»
Вообще я рад за ребят, что у них всё получается и им нравится то, что они делают. На этом все. Никаких дополнительных выводов для себя сделать не могу в виду отсутствия какой либо полезной информации.
Вообще я рад за ребят, что у них всё получается и им нравится то, что они делают. На этом все. Никаких дополнительных выводов для себя сделать не могу в виду отсутствия какой либо полезной информации.
Ушел на сайт Go, посмотрел презентацию, счкачал, учу.
Очень интересно какие были претензии к Erlang.
Меня всегда удивляют подобные комментарии. Почему сразу «слабаки! ниасилили»? Крупный и успешно развивающийся проект, почему вы считаете, что там сидят недоразвитые имбицилы, которые принимают решение на уровне «асилил/ниасилил»?
Между erlang/golang есть объективная разница (как на уровне языка, так и на уровне платформ(ы) для разработки) — у каждого свои плюсы/минусы. И даже если решение было принято не на основе этих объективных причин, а, например, на уровне «команда увереннее чувствует себя на go» (что вполне субъективно) — то в этом нет ничего плохого.
Между erlang/golang есть объективная разница (как на уровне языка, так и на уровне платформ(ы) для разработки) — у каждого свои плюсы/минусы. И даже если решение было принято не на основе этих объективных причин, а, например, на уровне «команда увереннее чувствует себя на go» (что вполне субъективно) — то в этом нет ничего плохого.
Erlang совсем не сложный язык (не сравнить с C++, Haskell или Scala), да и в OTP ничего сложного нет. Очень маловероятно, что причиной выбора Go было неосиляторство.
Скорее попали на такого себе консультанта, или вообще попытались взять тему «с набега» и не вписались во время отведенное для рассмотрения вопроса.
Подозреваю, проблема с Erlang'ом была в том, что тот не приспособлен под хоть сколько-то содержательную императивную логику — там удобно разве что фильтровать и перенаправлять потоки данных. Ну и производительность, очевидно, ниже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы перешли с 30 серверов на 2: Go