Интересно собирательное мнение о Rails

так на форумах обычно желчь излививают и набрасывают всякое на вентилятор, а не перетирают то, что все устали перетирать лет 5 назад

от себя добавлю, что все перечисленное для хипстеров, а реальные пацаны выбирают java и php

Гопники да, они такие, выбирают пхп и жабу и идут отжимать бабло у глупых заказчиков.

Сравнительный анализ с прямыми конкурентами (django, play etc.)

Такое же мало кому нужное поделие. когда-то все дрочили на Zope ну и где оно ? тоже самое с рельсами, джангами

непрямыми (node.js etc.).

у node.js может быть большое будущее в среднесрочной перспективе.

а так пацаны на текущий момент выбирают java / php. ананимус привет ! :D

Я не говорю, что rails будет жить вечно. Но на данный момент там все вполне адекватно и современно.

Zope-бум прошел мимо меня. Молод я еще. Но видимо он отмер как отмер ажиотаж и возбуждение вокруг CMF идеи. Задачи стали сложнее и перестали в нее умещаться. Ровно и так могут сдохнуть рельсы - как сдохнет идея синхронных веб-приложений.

Вот поддержки PHP я никогда не понимал. Не нравится мне его экосистема, вездесущие доллары, стиль языка и толпы быдлокодеров-школьников - хоть убей. Что угодно - женщин, бобров, детей, java'у - но не PHP. Инерция рынка, мать его. Хотя не могу спорить с тем, что достойные фреймворки для PHP таки написали.

Будь прокляты те дни, когда приходилось работать с drupal. И проблема даже не в drupal, а в том, что под него кодят как для говна и продают заказчику.

Бесят постоянно ломаемые обратные совместимости при апгрейдах.

Самый адекватный ответ в этом направлении заключается в том, что они (эти различные framework'и) примерно равны по возможностям и профиту. rails довольно не плохой framework, но лично я выбрал flask/django, из-за экостистемы питона(много хороших библиотек).

В rails мне очень нравится только ActiveRecord. В Django сетевая подсистема (роутинг etc.).

В рамках ruby 1.9-2.0 с rails 3.2.* - ничего не ломали.

в play (который RESTful by default), можно, при желании, развести стандартный нифига не-restful срач с глобально живущими в памяти массивами данных. В пыхах это невозможно технически, в питоне и руби возможно с бубнами (да, емнип, там и непринято так делать) Олсо, основываясь на этом, можно более удобно скрещивать сайт с веб-фреймворками, написанными на другой идеалогии (например, Wicket), если проект написан на нескольких непересекающихся или частично пересекающих веб-фреймворках одновременно.

в руби возможно с бубнами

С чего бы это, там же рантайм.

можно более удобно скрещивать сайт с веб-фреймворками

благодаря rack, в руби можно внутрь рельс запихнуть, например, приложение на синатре, и вообще любое приложение в конечном счете использующее rack.

помойму, между реквестами перегружаются экземпляры классов, а не сами классы. Поэтому можно юзать class members:

class ObjectCache
  @@objects = {:beagle => Beagle.new, :poodle => Poodle.new}

  def lookup key
    @@objects[key.to_sym]
  end
end

в продакшене так на автомате, в девелопменте включается ключиком

если не используешь рельсы, знакомые рубисты о какой-то технологии для этого рассказывали, но я не шарю

перегружаются экземпляры классов

очевидно, некоторые экземпляры классов.

между реквестами перегружаются экземпляры классов, а не сами классы.

Именно так, только я считаю это «без бубнов». Лучше не использовать @@ без лишней необходимости. Достаточно

class ObjectCache
  @objects = {:beagle => Beagle.new, :poodle => Poodle.new}

  def self.lookup key
    @objects[key]
  end
end

Именно так, только я считаю это «без бубнов».

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

Руби гораздо менее требователен к памяти, и по части потребления, система очень стабильна. А процу-то с чего кончаться...

rails + erlang/node.js/eventmachine подсистемы - стандартная практика.

Глобальные переменные - для меня это немного дико звучит. Если не конкретизировать. Если фреймворк stateless (rails, django) - то грех таким страдать. Если же экплуатируются websockets etc. - то здесь уже корневой считаю идею заложенную в erlang. В этом случае функциональное программирование тащит. Особенно immutable vars. Ибо ФП на уровне парадигмы решает проблемы масштабирования.

Печалька в том, что на erlang может оказаться плохо писать «цифромешалки». Друг сравнивал в этом плане erlang vm и jvm - по скорости выиграла последняя (более чем в 5 раз). Но архитектура процессов в erlang все же пока самая лучшая (из мной виденного).

node.js же кажется попыткой написать удобную асинхронию для тех, кто ниосилил ФП.

Пиратский сервер вова написан вообще на крестах, но больше 10к людей онлайна еле-еле держит даже на хорошем сервере с последними ксеонами и 128гб оперативки

значит надо на асме писать, он панацея.

Не так важно на чем. Главное качество кода и асимптотическая сложность алгоритмов.

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

ФП на уровне парадигмы решает проблемы масштабирования.

Главное качество кода и асимптотическая сложность алгоритмов.

Взаимоисключающие параграфы детектед.

Медленно. Дыряво.

некоторые хаки рельсов указывают на присутствие некоей магии

Да там и в самих рельсах в некоторых местах куча магии с автогенерирующимися в рантайме методами, которые в итоге не парсятся rdoc'ом и в целом крайне слабо документированы, приходится иногда в исходники лезть, чтоб понять, как эта хрень вообще работает и почему она не работает у меня.

Да нормальный Rails фреймворк. Если и правда интересно, что в Rails не так, то смотри сюда - http://blog.steveklabnik.com/posts/2011-12-30-active-record-considered-harmful и почитай книгу - http://railsoopbook.com/

В ней как раз описано в каких местах rails ломают ООП и почему, где не правильно названы классы (ActiveRecord) и много другого интересно.

Даже после прочтения шквала критики понятно, что такого же удобного аналога Rails нету. Rails отлично справляются со своей задачей, надо понимать когда и где их можно применять + важно знать ограничения ruby, всякие gil/gvm, кто и что может загружать память и как работает gc.

В общем я бы на твоем месте продолжал углубляться в руби и rails , прочитать http://patshaughnessy.net/ruby-under-a-microscope и начать изучать что-то паралельно (erlang/go etc), в конце концов жить только с ruby рано или поздно надоест.

grails