да, естественно

Надо смотреть конкретный кейс, часто руби под капотом использует C

Возможно вы просто не в потоковом режиме парсили

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

там сложная ситуация: один сервис пихает в очередь задач готовность данных, мы забираем у них огромные XML файлы, где самая главная проблема состоит в том что данные изначально не валидные, нам надо их пропарсить полностью и свалидировать, потом отдать в другую очередь джсон и уже готовые данные забрать, для руби - сложный кейс, на Си - проще

с крипто про была похожая ситуация, на каждую тачку надо покупать лицуху, ОС и ФСБ должны полностью все там проверить и все это проходит в течение года! Каждый раз этим заниматься - такое себе

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

У вас _уже_ есть, и встроено и работает - ну и красавчики.

А представим новую команду, решившую пилить новый стартап, да без кучи сидового бабла.
Шанс, что в такую рисковую команду попался человек, который грамотно умеет в микросервисы - есть, но не равен единице.
Даже если попался - теперь на нём обучение команды тому, как правильно готовить микросервисы (это как бы слегка сложнее чем монолит, по многим вопросам). А шанс, что собралась команда сениоров микросервисников, да на новый непонятный проект - не высокий.
И тогда команда тратят время(=деньги), на то, что не приносит ни денег ни юзеров. Итог часто печален.

Если-же никто микросервисы в команде не умеет, но решили сделать ибо "ну этож правильно и scalable" - можно списывать в утиль сразу.

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

Из мудрости, что выстреливает у тех, кто больше и чаще пробует, можно предположить, что быстрые прототипы на RoR монолитах, при прочих равных - будут чаще приводить к успеху, чем микросервисы.

Я не агитирую что все должны пилить микросервисы, а говорю что бывает это удобнее - все эти "если команда такая и т.д." никак этому не противоречит.
Я дал пару кейсов, где это в разы эффективнее и дешевле нежели пилить каждый раз с нуля :/
Это же не значит что везде так надо поступать, а под каждый кейс - свои инструменты.
Так что ещё раз скажу - все зависит от команды и требований. ну и естественно от количества проектов, сроков, перспектив на будущее и все такое

Так и есть.
Но почему тогда “от рельс уже сами рубисты плюются - DHH вошёл в режим стагнации и топит за то что микросервисная архитектура не нужна” 🤷‍♂️

Или DHH запрещает кому-то?

Я больше о том что рельсы - это 90% случаев "блог за 15 минут" и "прототип, а дальше сделаем норм", хотя потенциал у этого фреймворка куда выше

раньше рельсы - ВАУ
а сейчас - что за страшный и жирный Монстр?

Допустим выше, ок. Что DHH должен сделать по вашему?

ничего)

Переписать на go

Кому жирный, а кому и “о, тут всё есть для прототипа, не надо думать _лишний_ раз”

gin достаточно же)

не понял в чем стагнация тогда?
“он стагнирует”, но “делать ничего не надо” 🤷‍♂️

Dhh ещё ничего, а вот к матцу есть вопросы