Comments 76
О - ну что Вы коллега, несмотря на то, что jRuby 1.0 действительно почти полностью совместим с Ruby 1.8.6 и может работать почти со всеми Руби приложениями - JRuby ужасно медленный, медленнее раза в 2 чем стандартный Ruby.
В декабре 2007 выйдет версия 1.9 с переписанным ядром. Альфа версия доступна уже сейчас - и на некоторых тестах есть увеличение производительности в 3-4 раза.
А можно ссылки на тесты 1.9 версии.
Вот тут замечательное сравнение по скорости Ruby 1.8.5, JRuby, Ruby.Net и Ruby 1.9 (с новым ядром - которое называется YARV)
http://antoniocangiano.com/2007/02/19/ru…
Вот еще - более свежее
http://rubychan.de/share/yarv_speedups.h…
http://antoniocangiano.com/2007/02/19/ru…
Вот еще - более свежее
http://rubychan.de/share/yarv_speedups.h…
У самого Ruby есть так же немело минусов: отсутствие garbage collection, threads, IO и спецификации.
Чего-чего??? 0_о Автоматический сборщик мусора, IO, независимая от платформы реализация многопоточности - все есть.
Вот нынче есть уже наверное с десяток реализаций, не совместимых с друг другом.
Не десяток, а только 3 - о которых вообще стоит говорить. И все 3 один реализуют один и тот же стандарт языка - и Руби приложения работают одинаково на всех трех.
И чем же 1.8.6, YARV, JRuby допустим друг с другом не совместимы?
Спецификации нет - это конечно не совсем хорошо, но чем лично Вам (для примера) это мешает?
Как говорить - нормальная/не нормальная реализация многопоточности? Сейчас в Руби вообще другая модель реализации многопоточности - у которой есть как свои минусы, так и плюсы. Откуда Вы взяли "кучу проблем"? Причем в 1.9 будет и классическая модель многопоточности- на выбор.
А на счет
Жрет он может быть и ого-го - но все равно меньше чем Апач+FastCGI - так что тут вопрос - сравнивая работу этих двух серверов - какая реализация многопоточности лучше.
Спецификации нет - это конечно не совсем хорошо, но чем лично Вам (для примера) это мешает?
Как говорить - нормальная/не нормальная реализация многопоточности? Сейчас в Руби вообще другая модель реализации многопоточности - у которой есть как свои минусы, так и плюсы. Откуда Вы взяли "кучу проблем"? Причем в 1.9 будет и классическая модель многопоточности- на выбор.
А на счет
Именно из-за отсутствия нормальной многопоточности вы запускаете N-монгрелей, а не один и памяти он жрёт ого-го.
Жрет он может быть и ого-го - но все равно меньше чем Апач+FastCGI - так что тут вопрос - сравнивая работу этих двух серверов - какая реализация многопоточности лучше.
Ну как минимум Limitations раздел на сайте jruby, а как максимум - неизвестно) спецификации то с тест-сьютом нет)
Ага - а вот некоторые С/С++ компиляторы тоже не на 100% друг с другом совместимы - как же ими пользоваться, в продакшене то? :)))
Если серьезно - спецификации нет - кому что то нужно - читает исходники на С как спецификацию. Остальные как то живут без этого.
Но сейчас проблемы общеизвестные есть, и это факт.
Еще раз - перечисление реальных общеизвестных проблем можно? Кроме "монгрель должен выглядить как томкат" :))
Реализация и та, и другая не очень - ждём монгрель2)
Вам не угодишь :) У Монгреля - плохая многопоточность, у Апача - еще хуже - но "другой многопоточности у нас для Вас нет"(с) :)
Вообще очередной(уже серьёзный) бум должен быть после Ruby 2, Rails 2 & JRuby/IronRuby(быстрые и совместимые). А пока что ждём и следим)
Вот тут почти со всем согласен - только не "ждём и следим" - а нормально живем с тем что есть, а с 1.9 заживем еще лучше.
С 1.9 мы заживем шустро, но нестабильно. Испытательный полигон, dragons be here :)
http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9
http://www.rubyist.net/~matz/slides/rc2005/mgp00006.html
http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9
http://www.rubyist.net/~matz/slides/rc2005/mgp00006.html
Ох, не уверен я, что это правильная позиция - сокращать функциональность.
Не представляю, как вообще можно работать с вещью, с ограниченной функциональностью - когда собственные руки связаны чьим то мнением.
Неплохо было бы им вновь проанализировать проблематику и хорошенько обдумать - может существующий функционал следует изменить качественно, а не количественно...
Не представляю, как вообще можно работать с вещью, с ограниченной функциональностью - когда собственные руки связаны чьим то мнением.
Неплохо было бы им вновь проанализировать проблематику и хорошенько обдумать - может существующий функционал следует изменить качественно, а не количественно...
Предпочитаю Python. Хотя бы потому, что интерпретатор быстрее и, в отличии от Ruby, правила не диктуются одним-единственным фреймворком (Rails), а существует конкуренция между несколькими решениями. Например, Django и Pylons. Да и сам Python как язык мне симпатичнее. Хотя это конечно дело вкуса.
Предпочитаю Python. Хотя бы потому, что интерпретатор быстрее и, в отличии от Ruby, правила не диктуются одним-единственным фреймворком (Rails), а существует конкуренция между несколькими решениями.
"Вот так и рождаются нездоровые сенсации" (с) :)))
Кроме Ruby on Rails (который совершенно не виноват что он такой популярный :)
еще есть Ruby web фреймворки
Nitro
Merb
Maveric
и еще несколько - в каких то вещах даже более интересных, чем Rails - как например Merb - который значительно быстрее чем Rails и т.д.
Спасибо. Всегда полезно узнать что-то новое. Тем не менее именно Rails занимает господствующее положение.
З.Ы. Да я и не утверждал, что других фреймворков для Ruby нет (=
З.Ы. Да я и не утверждал, что других фреймворков для Ruby нет (=
Rails занимает господствующее положение - но ни кто ни кому ни каких правил не диктует - все по желанию - хочешь - используешь RoR, хочешь - Merb, а хочешь - пишешь web сайт вообще без фреимворков :)
А Python - замечательный язык. Для промышленных и бизнес приложений - самое то, особенно учитывая умопомрачительное количество питоновских библиотек на все случаи жизни. А на счет Django - не знаю :)
А Python - замечательный язык. Для промышленных и бизнес приложений - самое то, особенно учитывая умопомрачительное количество питоновских библиотек на все случаи жизни. А на счет Django - не знаю :)
Разумеется никто не диктует правил программисту, но вот разработчики веб-фреймворков оглядываются в сторону Rails. И если не дай бог что-то будет сделано не так "как в Ruby" поднимется жуткая шумиха.
Django кошерно ) Особенно если посмотреть на проекты, её использующие. Недавно Иван Сагалаев в своем блоге http://softwaremaniacs.org рассказал что Django и в Яndex любят )
Django кошерно ) Особенно если посмотреть на проекты, её использующие. Недавно Иван Сагалаев в своем блоге http://softwaremaniacs.org рассказал что Django и в Яndex любят )
Разумеется никто не диктует правил программисту, но вот разработчики веб-фреймворков оглядываются в сторону Rails. И если не дай бог что-то будет сделано не так "как в Ruby" поднимется жуткая шумиха.
Вы не совсем правы - как раз все мною перечисленные фреимворки сделаны совершенно подругому, и очень отличаются от Rails.
Другие фреимворки - как например PHP-шные - CakePHP, Symphony, CodeIgniter - их тоже можно понять - они ориентируются на лучшего из племени :) - это вполне понятно и объяснимо.
Django кошерно ) Особенно если посмотреть на проекты, её использующие.
Вот мне не удалось найти больших проектов, использующих Django :(- хотелось бы посмотреть на серьезном примере :(
Недавно Иван Сагалаев в своем блоге http://softwaremaniacs.org рассказал что Django и в Яndex любят )
Ага - читал, смотрел презентацию на RuTUBE - пример как то не убедил :) Совершенно не серьезная разработка - вот написал бы Яндекс свои блоги на Django - это был бы показатель, да :)
:) А меня как то эта учесть миновала :)
В чем граби? API запутанный?
В чем граби? API запутанный?
Значит мне повезло, что не пришлось туда залазить :)
С другой стороны очень большой плюс- сколько в питоне уже готовых хороших библиотек - к сожалению у Руби даже близко такого нет :( Как пример - нужна была мне библиотека для рисования графиков - у питона есть Matplotlib, Kiva, Chaco - и еще, которые я не смотрел. А что есть у нас? Gruff Graphs - совсем не равноценная альтернатива :(
С другой стороны очень большой плюс- сколько в питоне уже готовых хороших библиотек - к сожалению у Руби даже близко такого нет :( Как пример - нужна была мне библиотека для рисования графиков - у питона есть Matplotlib, Kiva, Chaco - и еще, которые я не смотрел. А что есть у нас? Gruff Graphs - совсем не равноценная альтернатива :(
Да это понятно ;) И я тогда эту проблему решил - тем более что перечисленные питоновские графические библиотеки работали как wrapper-ы для С++ библиотек :)
Но скажем так - некоторая скорость разработки была потеряна - и если бы готовое решение уже существовало - было бы намного приятнее работать - в этом отношении есть к чему стремиться.
Но скажем так - некоторая скорость разработки была потеряна - и если бы готовое решение уже существовало - было бы намного приятнее работать - в этом отношении есть к чему стремиться.
А вас никто не заставляет писать екстеншены к Python. Просто пишите на самом Python'е )
to North: а начать поиски с главной страницы проекта не пробовали? Там длиииинный список сайтов, построенных на Django или использующих её. http://djangoproject.com
to North: а начать поиски с главной страницы проекта не пробовали? Там длиииинный список сайтов, построенных на Django или использующих её. http://djangoproject.com
Camping забыли :)
>Да и сам Python как язык мне симпатичнее
Да нееее, руби намного красивее:
if flag
\t proc
против proc if flag )
Да нееее, руби намного красивее:
if flag
\t proc
против proc if flag )
не программист, просто некоторым образом имею отношение. хобби что ли ror для меня. ваяю на аптане по книжке шустрое уэб разработка на рельсах (Agile Web Development with Rails -тыреной pdf-ке). Очень не хватает книжек - желательно на русском и желательно бумажных.
что есть: http://xet.ru/rails
Вот вернее - Rails книжки, если тег не сьест
На русском и бумажных книг по RoR - с этим проблема.
Но вот если Вы работаете с Agile Web Development with Rails - то хочу Вам посоветовать очень хорошую книгу в таком же стиле
Beginning Ruby on Rails E-Commerce
Вот тут она + исходники к ней
http://ruby.rostovlinux.ru/rubylinks.htm…
И еще там же неплохая есть Rails Recipes - тоже неплохая книга.
Но вот если Вы работаете с Agile Web Development with Rails - то хочу Вам посоветовать очень хорошую книгу в таком же стиле
Beginning Ruby on Rails E-Commerce
Вот тут она + исходники к ней
http://ruby.rostovlinux.ru/rubylinks.htm…
И еще там же неплохая есть Rails Recipes - тоже неплохая книга.
Кто-нибудь может внятно объяснить, как и почему AWS съезжает с рельсов в угоду REST'у?
Вебсервисы всегда были удобным срезом между вьюшкоконтроллерами и функционалом.
Не ведут ли рельсы в сторону игрушечной песочницы, отрезанной от всего мира?
(можно в аську: 10 655 643, или даже голосом Skype: Neurosurg)
Вебсервисы всегда были удобным срезом между вьюшкоконтроллерами и функционалом.
Не ведут ли рельсы в сторону игрушечной песочницы, отрезанной от всего мира?
(можно в аську: 10 655 643, или даже голосом Skype: Neurosurg)
А Вы не могли бы свою мысль чуть подробнее развернуть? Не совсем понятна мысль :( - AWS как связан с обсуждаемой темой?
А сообразил :) AWS же никуда не девается - ну будет от плагином, а не в ядре - без проблем использовать как и раньше.
А вообще в глобальном споре SOAP vs REST - видимо команда RoR решила встать на сторону REST. На сколько я знаю во 2 версии работу с ресурсами через REST сделают вообще основой RoR - во всяком случае я слышал что то похожее.
И совершенно не "отрезанная от всего мира песочница" - REST модный тренд, который активно поддерживают Google, Yahoo, Amazon - через свои API как раз расчитанные на работу через REST.
И эта тесная интеграция с REST вполне может стать очередной фишкой RoR, которой нет у других фреймворков - так что я не вижу причин расстраиваться :)
А вообще в глобальном споре SOAP vs REST - видимо команда RoR решила встать на сторону REST. На сколько я знаю во 2 версии работу с ресурсами через REST сделают вообще основой RoR - во всяком случае я слышал что то похожее.
И совершенно не "отрезанная от всего мира песочница" - REST модный тренд, который активно поддерживают Google, Yahoo, Amazon - через свои API как раз расчитанные на работу через REST.
И эта тесная интеграция с REST вполне может стать очередной фишкой RoR, которой нет у других фреймворков - так что я не вижу причин расстраиваться :)
странно хабр не сообщил об ответе...
спасибо, понял. никогда не думал, что REST это что-то большее, чем стилистика оформления URL'ов. и уж совсем не разглядел, что REST может стаять противовесом SOAP... у последнего хотя бы спецификация есть, как я помню. а у REST?
North, там почта на гмейл ушла несколько часов назад.
спасибо, понял. никогда не думал, что REST это что-то большее, чем стилистика оформления URL'ов. и уж совсем не разглядел, что REST может стаять противовесом SOAP... у последнего хотя бы спецификация есть, как я помню. а у REST?
North, там почта на гмейл ушла несколько часов назад.
На счет спецификации не знаю. Но в плане использования в RoR я находил очень хорошие описания работы в некоторых книгах по Rails и есть замечательная публикация O'Reilly - Web Services on Rails - и это кроме достаточно большого количества просто статей.
на счет почты - кто то в Gtalk постучался и я добавил - Вы? :)
на счет почты - кто то в Gtalk постучался и я добавил - Вы? :)
Очень хочется поскорее познакомиться с Ruby On Rails 2.0
Sign up to leave a comment.
Ruby on Rails: чем меньше функционала — тем лучше