По моему опыту, редко, если вообще когда-либо, возникает необходимость писать серверные части вашего Rails-приложения на языке, отличном от Ruby.
Проблемы, с которыми сталкиваются такие компании, как Twitter, хорошоза пределами того, с чем когда-либо придется иметь дело большинству веб-приложений, и поэтому ради этого обсуждения их следует исключить.Twitter - крайний случай.
Тем не менее, в большинстве нетривиальных приложений Rails обычно есть требования для организации очередей и обработки фоновых заданий, хотя эти задания также обычно пишутся на Ruby.
Хорошее правило, которого следует придерживаться, заключается в том, что вы никогда не должны заставлять пользователя ждать и немедленно возвращать ответы на HTTP-запросы без ненужной привязки (с поддержкой Ruby) процессоров запросов.Например, если большое изображение загружено и требует ряда интенсивных преобразований - это следует делать асинхронно и автономно.Это также относится и к другим средам и языкам веб-приложений, независимо от их производительности.
Если вам требуется больше производительности для фоновых заданий, вы можете просто уменьшить количество рабочих процессов, обрабатывающих задания.Это также верно для обслуживания запросов Rails - вы можете, например, добавить больше рабочих процессов Unicorn для обработки большего количества запросов.
Хотя Ruby действительно значительно медленнее, чем C или разогретая JVM, обычно он "достаточно быстр".
Если вы используете MRI Ruby, вы должны использовать Ruby 1.9.3, который по крайней мере в два раза быстрее, чем серия 1.8.x, и немного улучшил сборку мусора.JRuby также работает хорошо и становится значительно более производительным с каждым выпуском.
Наконец, современные приложения на Rails значительно увеличивают объем обработки для клиента и обычно содержат больше JavaScript / CoffeeScript, чем раньше.Они часто используют более частичные обновления AJAX для View, что приводит к меньшему времени, затрачиваемому на рендеринг стека Rails, и меньшим, более легким запросам к базе данных со значительно меньшей обработкой Ruby на стороне сервера, чем, скажем, 4 года назад.
Наибольшие риски для вашего приложения не связаны с производительностью, и, как правило, это быстро меняющиеся требования и необходимость выполнения в срок и в рамках бюджета.Это справедливо для любого выбора технологии, хотя, как известно, Rails помогает смягчить последствия в этих областях.Я пишу это с позиции разработчика, который на протяжении многих лет использовал много фреймворков и языков, включая значительно более быстрые языки и стеки, например PHP, C # / ASP.NET MVC.