авторруби получается проще и веселее... пототипизировать. А как только реальных данных становится немного больше нуля (хотя бы по миллиону в основных таблицах + вспомогательные), так сразу приходится крячить серверный код чтобы хоть как то работало.

Рубевский ОРМ сильно слабее Hibernate.Так в этом случае же не руби становится проблемой - (с ним как-раз проще - докупить еще боксов для кластера да запустить на них дополнительные веб-серверы) а база - а какая ей разница руби это или жава, база ведь этого не знает, ей просто СКЛ приходит.

Про ОРМ в руби, так он умышленно сделан таким простым, если бы кто-то хотел добавить функционала - это было-бы просто - смержить туда кучу уже существующих плагинов и будет навороченный ОРМ монстр.
Там другая идеология - в 90% полностью хватает того функцинала что есть, а поскольку он очень простой - получается хороший и легкий код.
А как нужно что-то специализированное - вам предоставляется низкоуровневый доступ к базе (который вы тем-не -менее всеравно инкапсулируете в виде метода). В итоге по сложности получается почти то-же самое, потому что прочиать талмуд документации по хибернейт и научится все это правильно использовать или писать сложный СКЛ вручную - примерно по затратам одинаково выходит. В Рельсах решили что оно того не стоит. Поэтому однозначно сказать что какой-то из этих подходов лучше или хуже думаю нельзя.

Я когда в 2003 начал писать на ава и пришел в первую компанию - удивился - они писали в фаре, без подсказок и прочих фич редактора, но к счастью они был не против что я буду использовать IDEA. А в руби сначала тоже ужасался что нет редакторов с крутым рефакторингом и т.п. (сейчас кстаи появились - тот-же RedMine от JetBrains очень классный) - но я их не использую, а использую совершенно тривиальнейший ТекстМейт (даже не думал что когда-либо откажусь от редактора с подсказками) - просто потому что в руби код настолько компактный и естественный - что подсказки и всякие крутые фичи этих редакторов не нужны, а поскольку код легче и понятней - остается больше ресурсов на обдумывание самой задачи.

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

Но первые 2 уже в стадии решения (rubinius - виртуальная машина с байткодом) а 3й - теоретически также возможно будет решен, но с уверенностью сейчас это сказать пока нельзя.

автормодель в json генерить на жабе, и подпихивать это php - идиотизм полнейшийпо видимому это вы про мой пост написали, но вообще-то я имел ввиду совершенно другое - это не совсем "модель" а урезанная версия модели которая не содержит секретных данных и пересылается AJAX'ом напрямую в браузер в котором на основании этой "модели" JavaScript'ом собирается интерфейс. Никакого ПХП тут нет.