Комментарии 41
Лично я надеюсь в светлое будущее Rubinius
YARV идет правильным путем, поэтому не думаю, что в ближайшие лет 5 от него начнут отказываться.
Люди высказывайте свое недовольство в комментариях, а не просто сливайте опрос. Мне же очень интересно ваше мнение
Ruby Enterprise Edition
Через «c» интереснее получается :)
Подарочное решение, в виде большей скорости
Спорный вопрос :) особенно учитывая нововведения 1.9.3
Нововведения конечно хорошо, но как на самом деле дела обстоят? На rubyC говорили, что до REE ещё не дотянул
меня устраивает скорость (с ree не сравнивал), но больше всего мне нужен новый синтаксис хэшей и лямбд. так что ree идет лесом пока :)
Решил установить 1.9.3 в rvm и запустить последний проект, как протестирую отпишу
и он упал на библиотеке, которая использовала content_tag с символами и hash в параметрах
ммм. а подробности? ибо такая несовместимость врядли есть. только если гем какой-нибудь где-то прокололся.
да, gem упал на такой строчке
content_tag :div, :class=>"alert-message #{equal_bootstrap_class(type)} fade in", 'data-alert'=>'alert' do
content_tag(:a, '×', :href=>'#', :class=>'close') + content_tag(:p) {message.to_s.html_safe}#на этой строчке
end
а с какой ошибкой? :) я бы предположил что что-то с утфом.
А вот и нет, ошибка синтаксиса.
Видно ему явно надо указать, что последний параметр hash
syntax error, unexpected $end, expecting ')' content_tag(:a, '×', :href=>'#', :class=>'close...
Видно ему явно надо указать, что последний параметр hash
.html_safe можете убрать для rails 3 если не ошибаюсь. оно и так уже сейф приходит.
кстати, а почему не
<%= link_to 'x', '#', class: 'close' %>
<p><%= message %></p>
если честно, это мой gem облегчающий работу с bootstrap + rails. И html_safe я применил для того, чтоб запихнуть во flash message ссылку. Да звучит дико, но заказчики захотели.
Блок в content_tag? Что ж это за гем такой?
Мне кажется, не очень корректный опрос
Будущее ruby, как языка, я думаю будут задаваться в MRI, все остальные будут пытаться быть MRI совместимыми, может быть родят таки какой-то стандарт, но все равно он будет идти из этой реализации
А вот по платформам… Да фиг его знает. Пока на самом деле ничего кроме MRI + патчи в виде ree и MRI в виде 1.9.x ничего, на чем стоило бы продакшн делать я не вижу.
Будущее ruby, как языка, я думаю будут задаваться в MRI, все остальные будут пытаться быть MRI совместимыми, может быть родят таки какой-то стандарт, но все равно он будет идти из этой реализации
А вот по платформам… Да фиг его знает. Пока на самом деле ничего кроме MRI + патчи в виде ree и MRI в виде 1.9.x ничего, на чем стоило бы продакшн делать я не вижу.
Вся проблема в том что REE отстает фиг знает на слолько. У них даже нет 100% совместимости с MRI 1.8.7. Что очень прискорбно.
JRuby очень хорошо работает в бою.
Я как-то опасаюсь несовместимости gem-ов, которые построыены на native библиотеках. Тот же rmagick
Или там nokogiri?
Cовершенно не хочется писать отдельно Java версии этой логики.
Или там уже разрулили это?
Или там nokogiri?
Cовершенно не хочется писать отдельно Java версии этой логики.
Или там уже разрулили это?
Это с JRuby самое опасное. Надо понимать, что это НЕ MRI. И подход немножко другой. Из своего опыта я могу извлечь несколько простых правил, которые превратят JRuby в лучшее, что люди создали в Enterprise:
1) Это деплоится и работает не как Ruby, а как Java. А это значит, что после деплоя есть «прогрев» (пока оно сожрет кучу оперативки и все заоптимайзит) в течение которого оно будет работать медленее. И еще куча специфики, которая привычна Java-разработчикам и дика для тех, кто пришел из мира Ruby/Python (или даже PHP). Дайте коду прогреться и оно заработает не хуже MRI. По крайней мере у нас есть живые проекты, где он MRI откровенно уделывает. Незнание этой специфики Java отпугивает многих и рождает тьму статей в стиле «omfg! I'm so disapointed!».
2) Это не только Ruby, но и Java. Да, некоторых нативных библиотек может не быть. Но зато у вас есть ВСЯ Java под руками. Вы же понимаете, что там есть вагон и маленькая тележка библиотек для решения этих проблем. И местами они сильно лучше того, что есть для Ruby. Java действительно очень чисто импортируется и с ней приятно и удобно работать.
3) JRuby – это не горячая подмена для Ruby. Если взять и поменять для проекта X интерпретатор, все рухнет совершенно точно. Как минимум потому, что там базовые гемы другие. Но если код писался специально под JRuby (или JRuby держался в уме и тестировался) – вы на коне.
Нельзя рассматривать MRI и JRuby как конкурентов. Имхо, они решают совершенно разные задачи. У нас находится применение и первому, и второму. И есть проекты, которые одинаково хорошо запускаются на обоих и мы выбираем технологию в зависимости от предстоящего окружения.
1) Это деплоится и работает не как Ruby, а как Java. А это значит, что после деплоя есть «прогрев» (пока оно сожрет кучу оперативки и все заоптимайзит) в течение которого оно будет работать медленее. И еще куча специфики, которая привычна Java-разработчикам и дика для тех, кто пришел из мира Ruby/Python (или даже PHP). Дайте коду прогреться и оно заработает не хуже MRI. По крайней мере у нас есть живые проекты, где он MRI откровенно уделывает. Незнание этой специфики Java отпугивает многих и рождает тьму статей в стиле «omfg! I'm so disapointed!».
2) Это не только Ruby, но и Java. Да, некоторых нативных библиотек может не быть. Но зато у вас есть ВСЯ Java под руками. Вы же понимаете, что там есть вагон и маленькая тележка библиотек для решения этих проблем. И местами они сильно лучше того, что есть для Ruby. Java действительно очень чисто импортируется и с ней приятно и удобно работать.
3) JRuby – это не горячая подмена для Ruby. Если взять и поменять для проекта X интерпретатор, все рухнет совершенно точно. Как минимум потому, что там базовые гемы другие. Но если код писался специально под JRuby (или JRuby держался в уме и тестировался) – вы на коне.
Нельзя рассматривать MRI и JRuby как конкурентов. Имхо, они решают совершенно разные задачи. У нас находится применение и первому, и второму. И есть проекты, которые одинаково хорошо запускаются на обоих и мы выбираем технологию в зависимости от предстоящего окружения.
Да, я понял
Вообщем это хорошо когда много Java legacy кода. Я примерно так и предполагал.
Более того — есть слухи, что на последнем JDK7 JRuby 1.7 из последних билдов стал адскси быстрее.
Я кстати реально удивлен, что есть JRuby в production. Это какие-то выставленные в веб проекты? Или интранет + legacy корпоративный код?
Я собственно сам писал на Java и к Rails пришел через JRuby ( даже какие-то тикеты постил, когда он был совсем сырым)
Вообщем это хорошо когда много Java legacy кода. Я примерно так и предполагал.
Более того — есть слухи, что на последнем JDK7 JRuby 1.7 из последних билдов стал адскси быстрее.
Я кстати реально удивлен, что есть JRuby в production. Это какие-то выставленные в веб проекты? Или интранет + legacy корпоративный код?
Я собственно сам писал на Java и к Rails пришел через JRuby ( даже какие-то тикеты постил, когда он был совсем сырым)
И внешнее, и внутреннее. Причем в основном это банковское. И под хорошими нагрузками. Вы сильно недооцениваете популярность и распространенность JRuby. Это в нашем замкнутом русском комьюнити по какой-то неведомой причине он не прижился. Вы, например, знали, что у Visa есть эквайринговый шлюз, написанный на JRuby?
Для нас, как для людей, которые пытаются выжимать из людей забавные, но вставляющие изрядно в палок колеса, мифы о «enterprise» и «open-source» JRuby – грааль. Нужен IBM WebSphere за пицот мильонов долларов *фейспалм*? И SQL Server? На винде? Да не вопрос. Мы и с ними рельсы запустим :).
Для нас, как для людей, которые пытаются выжимать из людей забавные, но вставляющие изрядно в палок колеса, мифы о «enterprise» и «open-source» JRuby – грааль. Нужен IBM WebSphere за пицот мильонов долларов *фейспалм*? И SQL Server? На винде? Да не вопрос. Мы и с ними рельсы запустим :).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
По чей версии вы видите будущее Ruby?