Комментарии 82
Комбинация Ruby/RoR c *SQL — дает возможность БЫСТРО написать проект. Посмотреть «выстрелит» или нет. И если «все получилось» и нагрузка растет только так — уже можно не торопясь переписывать или оптимизировать «проблемные» части.
не менее быстро можно написать и на другом фреймвёрке, с которого миграция на производительную платформу будет легче. например grails + groovy++. вообще, конечно, каждый пишет на чём может и что знает лучше, но всё же лучше ориентироваться на производительные платформы с самого начала. посмотрите как фэйсбук сейчас мучается с php.
Назовите мне еще один framework, где есть настолько громадный набор сторонних библиотек (gems). RoR это уже давно конструктор и поэтому позволяет делать сложные сайты просто с фантастической скоростью. Я писал и на grails, и на play!, и на lift. Да, производительность JVM существенно выше, но мне пришлось писать просто дофига всего самому, где на RoR я в 99% подключил бы gem. Ruby потрясающи простой язык, если понять его концепцию. Scala — другой полюс, он гораздо сложнее нативной Java.
помнится искали мы что-нибудь для pam авторизации к ror — нашли только две бибилиотеки, одна кривая, другая падает. в groovy/java это уже есть изкаробки. Для grails кучи плагинов есть. Прежде чем ставить минус могли бы конкретно сказать, чего вам не хватает.
У вас старые данные про RoR. Буквально за последний год очень много добавилось, стало стабильным, включая PAM модули, поиск на Sphinx, ACL, работа с ДОБД, работа с key-value, пейджинг, крамбы и прочее работает весьма надежно. Хотя, безусловно, java всегда впереди планеты всей, например в направлении семантик веба, на роре в сравнении с явой это очень неразвито.
>Назовите мне еще один framework, где есть настолько громадный набор сторонних библиотек (gems).
java/maven
java/maven
Нет, это не так. Грельсы отстают на много-много лет от рельс.
Смотря с какой стороны посмотреть:
1. Grails более идеологически стабилен, там нет таких функциональных скачков от релиза к релизу.
2. Grails безумно растёт в Enterprise & Java Shop'ах — мейл лист у него один из самых активных среди Java Web Frameworks. Во многом этому способствует официальная поддержка SpringSource.
3. Наряду с проверенными || монстроузными (как кому больше нравится) Spring & Hibernate там появляется поддержка аутентичных Geb, Spock, Gradle.
Так что честно говоря не вижу в чём ему отставать если у него совершенно другой рынок и ЦА.
1. Grails более идеологически стабилен, там нет таких функциональных скачков от релиза к релизу.
2. Grails безумно растёт в Enterprise & Java Shop'ах — мейл лист у него один из самых активных среди Java Web Frameworks. Во многом этому способствует официальная поддержка SpringSource.
3. Наряду с проверенными || монстроузными (как кому больше нравится) Spring & Hibernate там появляется поддержка аутентичных Geb, Spock, Gradle.
Так что честно говоря не вижу в чём ему отставать если у него совершенно другой рынок и ЦА.
А если взять другую популярную связку Python + Django? Интересно, как тут обстоят дела с масштабируемостью и производительностью? И вообще, почему не так часто используют PostgreSQL
В реальной жизни PostgreSQL используют чаще для технологически-сложных проектов, просто у его пользователей не возникает такого количества проблем, о которых можно писать статьи :)
если сравнивать в ruby 1.8, то быстрее, если с 1.9 — то одинаково, т.е. всё так же далеко от JVM
JRuby не сильно медлее Groovy
для groovy есть groovy++, java и gpars, а про проблемы с jruby написано в оригинальной статье
В оригинальной статье есть просто конкретное замечание к JRuby со стороны twitter инженеров в том плане, что они написали дохрена всего под CRuby и переписывать не собираются. Я просто указал на то, что нельзя сравнивать Ruby и JVM, так как под JVM есть тот же Groovy, который не быстрее Ruby, исполняющийся под тем же JVM via JRuby, и есть, например, native Java — которая действительно рвет в тряпки Ruby.
>они написали дохрена всего под CRuby и переписывать не собираются.
переписали они в контексте оптимизации, ибо нативная ruby/jruby версия тормозит.
>так как под JVM есть тот же Groovy, который не быстрее Ruby, исполняющийся под тем же JVM via JRuby
как правило он быстрее плюс значительно проще ускоряется методами выше
переписали они в контексте оптимизации, ибо нативная ruby/jruby версия тормозит.
>так как под JVM есть тот же Groovy, который не быстрее Ruby, исполняющийся под тем же JVM via JRuby
как правило он быстрее плюс значительно проще ускоряется методами выше
С таким подходом легко угробить проект. Представьте себе ситуацию (вполне реальную), что вы анонсировали некий сервис на хабре. Людям оный понравился, включилось сарафанное радио и нагрузка на систему начинает расти экспоненциально, доходя до точки бифуркации, что приводит к обрушению.
Для онлайн-проектов первое впечатление самое важное, так что рухнувшая на старте система теряет множество баллов, и за время латания дыр финансово обеспеченные игроки вполне могут успеть выстрелить улучшенным и устойчивым клоном.
Для онлайн-проектов первое впечатление самое важное, так что рухнувшая на старте система теряет множество баллов, и за время латания дыр финансово обеспеченные игроки вполне могут успеть выстрелить улучшенным и устойчивым клоном.
НЛО прилетело и опубликовало эту надпись здесь
Проблема в том, что Твиттер изначально развивался не как, например, Фейсбук. Тви делался сначала для быстрого общения друзей (лицокнига начиналась с целого университета), а потом у него не было ограничений на регистрацию (фейсбук распространялся в специально отобранных кампусах), кроме того, его открытое АПИ сильно стимулировало разработчиков, которые дергали сервера сервиса все большим количеством запросов. В результате этого Твиттер периодически рос экспоненциально, показывал кита, падая от нагрузки, отключал поиск… Ситуация требовала вмешательства тактического (чтобы поправить) и стратегического (чтобы справиться с все возрастающими потребностями).
В живом цикле разработки все сложнее, чем «сразу сделать все грамотно».
В живом цикле разработки все сложнее, чем «сразу сделать все грамотно».
Лучше сделать правильную архитектуру приложение, так чтобы можно было БЫСТРО отмаштабироваться горизонтально и были места для оптимизации. Ну да, сначала можнт быть волна, не будет слэшдот/дигг-эффект — взяли на это время по-большие инстансов, потом все успокоилось и вырубили инстансы лишнии.
Но это не означает, что можно сделать все медленно и неправильно оставляя все на рефакторинг и оптимизацию.
Но это не означает, что можно сделать все медленно и неправильно оставляя все на рефакторинг и оптимизацию.
> И если «все получилось» и нагрузка растет только так — уже можно не торопясь переписывать или оптимизировать «проблемные» части.
Есть оно действительно «выстреливает», то «не торопясь» обычно не получается.
Есть оно действительно «выстреливает», то «не торопясь» обычно не получается.
Видно что переводил человек, не знакомый с Java. NIO это API JavaSE
Когда число посетителей сравняется с аудиторией твитера, то уже можно и перейти с RoR на что-то другое. Да ну хоть на ассемблере бэкэнд переписать для скорости (-: Человеческие и финансовые ресурсы это позволяют.
Есть другая сторона медали. Когда приходится проектировать систему, которая неизбежно «выстрелит» (хотя бы по причине вливаемых в рекламу средств), то тайм-аута на переписывание, по мере роста нагрузок, не будет. Так что приходится сразу же планировать масштабируемость и устойчивость. И тут рельсы/джанго годятся только для внутреннего прототипирования.
Я вас умоляю. Масштабировать проект на рельсах так же просто/сложно как и на других фреймворках. Запустил больше воркеров и всё.
Главные сложности возникают всегда с масштабированием БД. А это уж от языка не зависит.
Главные сложности возникают всегда с масштабированием БД. А это уж от языка не зависит.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Но это же не значит что рельсы/эрланг не масштабируются. Масштабируются, просто дороже.
А для монстров рынка (твиттеры там, фейсбуки всякие) общие правила всё равно не действуют.
А для монстров рынка (твиттеры там, фейсбуки всякие) общие правила всё равно не действуют.
Но опять надо сравнивать издержки не только на количество серверов, но и на стоимость работы программистов, причём не только для начальной разработки, но и для поддержки и развития. Грубо говоря, переписывание всего софта на ассемблере освободит просто куеву хучу ресурсов в мировых масштабах, но вот сколько будет стоить его переписать…
Ну не на С++, а на С и не 10к а 6к :) пруф
Вот именно, **специфическая задача**. Именно их имеет смысл «переписывать на ассемблере». И то только после результатов профилирования.
Писать же всю систему сразу на С не имеет смысла.
Про десятое правило Гринспуна все помнят? :-)
Писать же всю систему сразу на С не имеет смысла.
Про десятое правило Гринспуна все помнят? :-)
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Ну я не знаю ни одной системы, которая на этапе проектирования и запуска «неизбежно выстрелит». Твитер, Фб и т.п. на момент старта вряд ли предполагали такой отклик. С другой стороны, гораздо больше систем, которые задумываются, как вполне себе способные выстрелить, на поверку оказываются никакущими. Пример — гугловские волны. Уж сколько было потрачено человекочасов и средств, а отдача — 0.
Нужно быть немного чокнутым (или гением, что почти одно и то же), чтобы планировать «выстреливание» больших систем. Но помимо них существует множество вариантов, где можно пострелять не слонов, а дичь помельче. Более того, у малых и средних проектов значительно лучше продуманные изначально бизнес планы, а прибыль в очень короткие сроки покрывает все расходы на разработку и обслуживание. Всё же деньги делаются не только на раздувании гигантских пузырей, но и на пускании множества маленьких пузырьков :)
Чего я в тексте пропустил, если я так и не увидел чего-то, кроме повторения факта «Twitter переезжает с руби на java»?
Никакого более детального раскрытия информации, обзоров, цифр и результатов. Это что, пост?
Никакого более детального раскрытия информации, обзоров, цифр и результатов. Это что, пост?
Опять эта тема твиттера и руби… Руби не повезло, что самый большой сайт на нём принадлежит такой странной в техническом отношении компании как твиттер. Несколько примеров… Они написала очередь сообщений на руби (кому вообще могло прийти в голову писать такое на руби во времена черепашьего 1.8?!, причём судя по тестам их реализация была очень далека от оптимальности...) — переписали на скале — по блогам пошли посты на тему; руби дрянь, скала рулит. Переписали поисковую подсистему на JVM с иcпользованием асинхронных запросов к бэкенду через netty — скорость выросла в 10 раз — все снова сделали вывод: руби дрянь, хотя если бы они переписали синхронный код на руби с иcпользованием асинхронности через event_machine, рост производительности был бы таким же огромным.
Плюс странные заявления, что Scala лучше ruby потому, что там статическая типизация, что снижает кол-во ошибок. Надёжность программ со статической типизацией это просто миф, в который верят люди у которых мало опыта с динамическими языками.
Из постов в блогах кажется, что Твиттер компания, где решают все проблемы переходом на новую более модную технологию и написанием своих велосипедов на ней…
Плюс странные заявления, что Scala лучше ruby потому, что там статическая типизация, что снижает кол-во ошибок. Надёжность программ со статической типизацией это просто миф, в который верят люди у которых мало опыта с динамическими языками.
Из постов в блогах кажется, что Твиттер компания, где решают все проблемы переходом на новую более модную технологию и написанием своих велосипедов на ней…
Из постов в блогах кажется, что Твиттер компания, где решают все проблемы переходом на новую более модную технологию и написанием своих велосипедов на ней…
Но похоже этот подход оправдан, не так ли?
Языки со статической типизацией более надежны, это факт. Их компиляторы устраняют 100% ошибок, связанных с неправильными типами.
НЛО прилетело и опубликовало эту надпись здесь
Я ему про Фому, он мне про Ерёму.
При чем тут Эрланг и его динамическая типизация?
При чем тут Эрланг и его динамическая типизация?
НЛО прилетело и опубликовало эту надпись здесь
Надежность бывает разная, конечно же.
В иных языках приходится каждый параметр обрабатывать утиной типизацией. «Если у него есть такой метод, то делаем то-то». Не спорю, это позволяет делать волшебные штуки.
Но иногда хочется просто сказать «этот параметр является тем-то». И пусть компилятор за тебя проверяет, а не передал ли кто-нибудь в этот метод чего лишнего. Когда можешь положиться на компилятор, то это же тоже надежность, не так ли?
В иных языках приходится каждый параметр обрабатывать утиной типизацией. «Если у него есть такой метод, то делаем то-то». Не спорю, это позволяет делать волшебные штуки.
Но иногда хочется просто сказать «этот параметр является тем-то». И пусть компилятор за тебя проверяет, а не передал ли кто-нибудь в этот метод чего лишнего. Когда можешь положиться на компилятор, то это же тоже надежность, не так ли?
Без динамической типизации в Эрланге было бы трудно сделать горячую замену кода. Тем не менее, он тоже движется в этом направлении: спецификации типов все-таки не зря ввели.
Каст в object а потом обратно в неправильный class ваш супер надежный компилятор то же обработает? А если у функции, например, 5 аргументов с типом string и я перепутал местами (или кто то поменял местами) аргументы — то же компилятор найдет? 100% ошибок (я утрирую, конечно) устранят unit test'ы. А их пофигу для чего писать, javascript, ruby, java.
Каст в object а потом обратно в неправильный class
Конечно. В С#, например, есть конструкция as. Если этот объект на самом деле не является тем, к чему ты его хочешь привести, она вернет null.
Пример с перепутанными аргументами вообще не в кассу.
Комплятор в compile time скажет, что тип неправильный или нет, при использрвании as? Или ошибка будет в runtime (NullPointerException)?
Почему пример с перепутанными аргументами не в кассу? Разве вызов метода и его проверка в compile time это не часть type safety компилятора?
Почему пример с перепутанными аргументами не в кассу? Разве вызов метода и его проверка в compile time это не часть type safety компилятора?
> Комплятор в compile time скажет, что тип неправильный или нет, при использрвании as? Или ошибка будет в runtime (NullPointerException)?
Надо понимать что as, reinterpret_cast и подобные средства — это средства на крайний случай. В большинстве случаев они не нужны. Если ты хочешь выстрелить себе в ногу (специально), то языки обычно дают тебе такую возможность. И если ты кастишь вниз по иерархии, будь добр проверить на null.
> Почему пример с перепутанными аргументами не в кассу? Разве вызов метода и его проверка в compile time это не часть type safety компилятора?
> А если у функции, например, 5 аргументов с типом string
Ты сам то понял что сказал?
Надо понимать что as, reinterpret_cast и подобные средства — это средства на крайний случай. В большинстве случаев они не нужны. Если ты хочешь выстрелить себе в ногу (специально), то языки обычно дают тебе такую возможность. И если ты кастишь вниз по иерархии, будь добр проверить на null.
> Почему пример с перепутанными аргументами не в кассу? Разве вызов метода и его проверка в compile time это не часть type safety компилятора?
> А если у функции, например, 5 аргументов с типом string
Ты сам то понял что сказал?
Хм, то есть
«Языки со статической типизацией более надежны, это факт. Их компиляторы устраняют 100% ошибок, связанных с неправильными типами.»
это лажа, так?
И компиляторы все же не дают 100% надежность при работе с типами, да? И как только мы кастим к базовому типу, то вся 100% надежность идет к чертям?
Кто то не врубается что такое type safety, видимо не доходит, что компилятор не может гарантировать 100% отлавливание ошибок работы с типами, потому что в каждом языке есть дыра, когда можно все эти проверки послать к черту.
Ну если не доходит, то и спор бессмысленный.
«Языки со статической типизацией более надежны, это факт. Их компиляторы устраняют 100% ошибок, связанных с неправильными типами.»
это лажа, так?
И компиляторы все же не дают 100% надежность при работе с типами, да? И как только мы кастим к базовому типу, то вся 100% надежность идет к чертям?
Кто то не врубается что такое type safety, видимо не доходит, что компилятор не может гарантировать 100% отлавливание ошибок работы с типами, потому что в каждом языке есть дыра, когда можно все эти проверки послать к черту.
Ну если не доходит, то и спор бессмысленный.
Имхо, тут у кого-то с логикой проблемы.
>Автомобили более безопасны, чем мотоциклы, это факт.
>А от попадания ядерной бомбы автомобиль защитит? Или от падения со 100 метрового обрыва? Нет! Значит автомобили не безпаснее мотоциклов! От всего вышеперечисленного спасет только радио «Радонеж»
>Автомобили более безопасны, чем мотоциклы, это факт.
>А от попадания ядерной бомбы автомобиль защитит? Или от падения со 100 метрового обрыва? Нет! Значит автомобили не безпаснее мотоциклов! От всего вышеперечисленного спасет только радио «Радонеж»
Ваш пример с кастом на самом деле надуманный. Каст обходится в 99% случаев с помощью параметризированной типизации. А в тот момент, когда параметризированные типы не «срабатывают», надо просто внимательно посмотреть на то, как мы пытаемся их применять. Generics — относительно новое понятие для мейнстрим-разработчиков. Я сам отлично помню, как путался с ними лет пять назад. Сегодня же единственные случаи когда мне приходится использовать cast — это работа со старыми или плохо адаптированными к generics библиотеками.
Самый возмутительный пример: в JPA метод getResultsList() объекта Query возвращает нетипизированный список. Во многих проектах утилитарная функция его приведения — единственное место, где я реально использую cast.
Самый возмутительный пример: в JPA метод getResultsList() объекта Query возвращает нетипизированный список. Во многих проектах утилитарная функция его приведения — единственное место, где я реально использую cast.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ну а почему Вы лезите сюда с провокационными заявами — РОР кал — ПХП — чудо?
Здесь и так горюют рубисты, в том числе и я.
Дело не в том, что кто-то что-то переделывает во имя чего-то.
А как раз в том, что «кто-то что-то переделывает во имя чего-то.»
Улавливаете? Людям же насрать, что Твиттер в большинстве своем выстрелил благодаря Руби/рор.
Что развертка и масштабирование было в реалтайме. Что можно было диманически и довольно быстро учитывать пожелания клиентов/юзеров.
Людям настрать, что запросы к бд выросли с сотен до миллиардов обращений! У вас есть проект с такими запросами?
Людям насрать на то, что поддерживать рор проект намного лечге и экономически выгоднее, чем держать свору высококвалифицированных С/++ специалистов.
Люди слышат одно — Твиттер отказывается от Руби.
Значит Руби — кал! На кол его! Скала рулит! Хотя до этого момента абсолютное большинство даже и не догадывалась о существовании оного.
Да, обидно, чертовски обидно видеть как на ЯП сказывается политика одной, хотя и большой компании.
Но Мац далеко не дурак. Он увидел потолок. Предел. Что нужно оптимизация ради экономии.
Он уже над этим работает. (Я надеюсь..)
1.9 ветка была не об этом.
Кстати — твиттер страртовал еще на 1,8 руби со всеми вытекающими.
Если они до сих пор были на нем — это говорит об огромном потенциале.
Но люди же не слышат этого. ТВИТТЕР ОТКАЗЫВАЕТСЯ ОТ РУБИ! — вот всё, что на слуху.
А тут Вы еще со своим пхп.
Здесь и так горюют рубисты, в том числе и я.
Дело не в том, что кто-то что-то переделывает во имя чего-то.
А как раз в том, что «кто-то что-то переделывает во имя чего-то.»
Улавливаете? Людям же насрать, что Твиттер в большинстве своем выстрелил благодаря Руби/рор.
Что развертка и масштабирование было в реалтайме. Что можно было диманически и довольно быстро учитывать пожелания клиентов/юзеров.
Людям настрать, что запросы к бд выросли с сотен до миллиардов обращений! У вас есть проект с такими запросами?
Людям насрать на то, что поддерживать рор проект намного лечге и экономически выгоднее, чем держать свору высококвалифицированных С/++ специалистов.
Люди слышат одно — Твиттер отказывается от Руби.
Значит Руби — кал! На кол его! Скала рулит! Хотя до этого момента абсолютное большинство даже и не догадывалась о существовании оного.
Да, обидно, чертовски обидно видеть как на ЯП сказывается политика одной, хотя и большой компании.
Но Мац далеко не дурак. Он увидел потолок. Предел. Что нужно оптимизация ради экономии.
Он уже над этим работает. (Я надеюсь..)
1.9 ветка была не об этом.
Кстати — твиттер страртовал еще на 1,8 руби со всеми вытекающими.
Если они до сих пор были на нем — это говорит об огромном потенциале.
Но люди же не слышат этого. ТВИТТЕР ОТКАЗЫВАЕТСЯ ОТ РУБИ! — вот всё, что на слуху.
А тут Вы еще со своим пхп.
Люди видят то, что хотят видеть. Даже есть вы двести раз повторите в корне логичную и разумную мысль, человек все-равно преобразует ее в то, что его разуму более понятно.
Я к тому, что внимательные и грамотный читатель не видит в заголовке «Твиттер отказывается от Руби», этого и не подразумевается — Эван Уивер говорит о том, что Ruby (RoR) до сих пор остаются очень хороши для решения некоторых поставленных задач. Просто не всех.
В конце-концов, вы же не думаете, что Ruby и его аудитория пострадают из-за того, что Twitter переносит часть своих технологий на другие языки/инструменты/платформы? Я думаю, большую часть выгоды он уже получил. А если развитие и дальше пойдет текущими темпами, то все-равно этот язык, как и фреймворк, войдет в историческую когорту «самых популярных». Даже я, человек очень далекий от фактического программирования (не то мышление) пытался освоить азы ООП именно с этого языка, т.к. его синтаксис прост до безумия.
Или вам неприятно видеть Ruby в качестве стартовой ступени разработчика?
Я к тому, что внимательные и грамотный читатель не видит в заголовке «Твиттер отказывается от Руби», этого и не подразумевается — Эван Уивер говорит о том, что Ruby (RoR) до сих пор остаются очень хороши для решения некоторых поставленных задач. Просто не всех.
В конце-концов, вы же не думаете, что Ruby и его аудитория пострадают из-за того, что Twitter переносит часть своих технологий на другие языки/инструменты/платформы? Я думаю, большую часть выгоды он уже получил. А если развитие и дальше пойдет текущими темпами, то все-равно этот язык, как и фреймворк, войдет в историческую когорту «самых популярных». Даже я, человек очень далекий от фактического программирования (не то мышление) пытался освоить азы ООП именно с этого языка, т.к. его синтаксис прост до безумия.
Или вам неприятно видеть Ruby в качестве стартовой ступени разработчика?
Мне? Да я уже год как не представляю иного ничего такого же быстрого и наименее затратного.
Руби в юниксе уже есть.
Всё, что нужно поставить -гемы или рвм. Далее рор.
Далее гитхаб.
Далее хероку.
И все это парой строкой в баше.
Это же прекрасно!
Руби в юниксе уже есть.
Всё, что нужно поставить -гемы или рвм. Далее рор.
Далее гитхаб.
Далее хероку.
И все это парой строкой в баше.
Это же прекрасно!
Эм… Каким-таким функционалом обрастал Твиттер, что приходилось «диманически и довольно быстро учитывать пожелания клиентов/юзеров»?
Проблема была одна — тормоза и стабильность. Функционалам обрастала экосистема вокруг Твиттера, которую он потом начал скупать или имплементить самостоятельно — но уже в пост-RoRовские времена.
Проблема была одна — тормоза и стабильность. Функционалам обрастала экосистема вокруг Твиттера, которую он потом начал скупать или имплементить самостоятельно — но уже в пост-RoRовские времена.
НЛО прилетело и опубликовало эту надпись здесь
PHP стал быстрее, функциональнее и удобнее в последней версииЭто как заявить «Лада стала быстрее/надежнее/удобнее» в топике о том, как како-нибудь олигарх пересел с Феррари на Майбах.
Поменяли один RunTime, на дргуой чуток побыстрее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миграция с Ruby