… и при этом на настройку уходит не больше десяти минут, есть поддержка авторизации как минимум тремя методами(включается одной строчкой конфига), за считанные минуты можно прикрутить openid/oauth/fbconnect

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

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

FaceBook сами признали, что php они выбрали зря. Если хотите, кину пруф на конференцию.

Да какая все-таки разница, кто реализовал fastcgi: авторы языка или его пользователи?

Профита не вижу ни для себя, ни для, тем более, заказчика, что ему есть за что переплачивать хотя бы за хостинг/администрирование vds.
Скорость и качество разработки.

А хостинг, как уже сказали, можно сделать и бесплатный(GAE для Django или Heroku для Rails)

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

Что говорит о более высоком пороге входа(всего на одну небольшую книжку!), но почему это должно становиться таким существенным аргуентом против данной технологии?

Когда я пишу типичное веб-приложение с нуля, без использования повторно используемого кода

Так зачем?

heroku.com — лучшый друг новичка в RoR.

Как раз ruby(точнее, rails и прочие фреймворки) более чем дружелюбны к вебу.
Встроенная поддержка актуальных трендов(ajax, rest, etc...), встроенное управление серверным и клиентским кешированием(поведением которого можно управлять) и т.п.
Просто порог входа выше, нужно суметь понять и поместить в голову архитектуру прилжения(фреймворка).

Для асинхронного программирования в руби есть, например, EventMachine.
GreenThreads тоже есть. И Fibers.

Почему это трудно?
И чем вам REST не угодил?

Вы думаете, что без понимания вышмата можно стать хорошим программистом?

Альфабанк.

А нет, соврал. По умолчанию используется стратегия :checkout, которая сохраняет служебные файлы и директории. Просто на RoR это как-то не особенно важно(до .git, лежащего в корне, никак не добраться. Все запросы роутятся обычно в контроллеры и в директорию public для статики).

Да, сможет.
Логики в конфигах capistrano почти нет, там по сути только задание переменных и описание задач.
О режимах деплоя в капистрано по-русски хорошо написано здесь. Если используется репозиторий, служебные файлы(.git, .svn и тп) в релиз не попадут.

Если для вас не критична смена паспортных данных, вы можете «потерять» паспорт и написать об этом заявление в милицию. Начиная с даты, указанной в заявлении, все операции по старому паспорту будут недействительны.

Разрабатываю api, используя Restfulie.
О том, каким должно быть api, отлично написано в pdf-ке.

Между тем, и Google, и Facebook, и Twitter и Microsoft имеют много своих разработок в области тех же СУБД.
Хотя ваша мысль ясна и, несомненно, верна.