Ключевые слова здесь: “стартапер” и “I never questioned this stack [JS]…”

Из моего опыта работы над высоконагруженными проектами на JS стэке и близкого наблюдения за Scala-JVM стэком
добавлю, что область применимости и выгоду Ruby on Rails в больших компаниях сильно недооценивают.

Ведь любую большую компанию можно разделить на много маленьких, что и делают амазон, wix и многие другие.

А скорость и качество реакции на изменения рынка определяют жить компании или умирать in the long run.

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

Реальность: проблемы легче масштабируются в других стэках, но тушаться пожары еще дороже, потому что во-первых все равно нужно хотя бы 1-2 умных и дорогих лида с ЗП всего на 10-20% ниже умных рубистов.

Но если 2 умных рубиста могут быть самодостаточным юнитом, то для сравнимой по масштабам задачи в JS к ним еще надо докупить несколько середнячков разгребать ???? и рутину. Это не считая DBA и прочий инфра люд.

И все равно по скорости разработки они будут уступать 2м крутым рубистам. Хотя бы из-за расходов времени на коммуникацию.

Любопытно, что эти же рассуждения применимы к паре Scala - Nodejs (в пользу ноды), с тем отличием, что умных скалистов (а не косящих под них недо-джавистов, тысячи их) хер найдешь.

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

Вот что об этой паре думает PayPal: https://engineerbabu.com/blog/node-js-the-rising-technology-behind-paypal/

Другими словами для сферического веб-проекта в вакууме шкала реальной себестоимости бэкенд стэка (с учетом костов потерянного времени разработки, от самого дорогого к дешевому):

Scala/Java → Nodejs → Ruby

Да, монолитность и MVC паттерн пугают своей негибкостью и не масштабируемостью. Да и с non blocking IO, мультитредингом все не так круто, как хочется в большом проекте…

И это действительо очень серьезный барьер для входа в высшую лигу (в основном i/o и треды, mvc паттерн и монолит больше страшилка для неопытных лидов).

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

Это конечно абстрактно в вакууме, в каких-то проектах сработает, в других быстро упремся в стенку.

Но дойти до глубокого анализа этой проблемы, а не бездумно выбрать стэк "как все” — это уже ⭐️ на погоны RnD менеджеру.

Да, может показаться, что “уж если у нас сложный фронт на Реакте, то зачем плодить зоопарк технологий, будем JS based компанией/командой. Сэкономим на логистике, процессах, инфре, найме и т.п.”

На деле барьер между JS/Ruby гораздо ниже, чем многие эффективные менеджеры себе представляют (а значит и их прогнозы, модели дают неверные предсказания).

Простыми словами — любой толковый рубист за пару дней сделает то, что JSник будет колупать неделю и в свободное время на сдачу не обломается и на Реакте сбацать что-то рабочее.

А если нужно на Реакте лабать по красоте — один хер нужен эксперт в Реакте, а не просто JS разработчик. Поэтому желание сэкономить, нанимая “фулл-стэк JS” разработчиков, обычно приводит к тому, что скупой платит дважды.

— Но руби медленный!
— Да скорость разработки, твою мать ????

Единственный серьезный аргумент в пользу JS для бэкенда, это аргумент найма.
Разумеется “при прочих равных” для сферической веб-компании в вакууме. Реальные же кейсы могут иметь свои очень неожиданные особенности и требования.
Менеджмент (если он не просто “как все”, а подошел к проблеме осознанно) по сути должен взвесить как в той бессмертной миниатюре (https://youtu.be/TkL54oQgf6I) раки большие (рубисты, которые в N раз быстрее/лучше решают задачи), но по 5 или маленькие, но по 3.

И это решение без готового правильного ответа. Играет роль и природа проекта, и вижн, и планы, и скорость роста, и насколько хорошо вы умеете хантить людей и многое другое.
Сюда же относится проблема легаси. Если исторически так сложилось, что вовремя не распилили архитектуру и компанию на юниты, то с руби без типизации будет сложно.
Да и рельсы не заточены под большие размеры команд на один артефакт

Ссылка на русский источник: https://t.me/rubyrush/82218