Вот как вредно на Go писать.

на руби или на рельсе? Если нужно + 10x к скорости, то просто этот кусок переписываешь на Roda и ок)

Человек сейчас живет лучше меня))

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

Ты, человек, не понял. Там проблема была не в скорости приёма HTTP запросов и посылки ответа. Там была туева хуча бизнес-логики. Просто переписывание её с Go на Ruby замедлило бы выполнение в десятки раз, даже если это будет супер-лайт-вейт рубишный фреймворк.

Это про "интерпретатор vs компилируемый язык"

логика на руби только тогда ощутимо тяжелей, когда надо обрабатывать много объектов

Там было (и есть) много объектов, и ещё больше кода их обработки.

И всё это индивидуально для каждого пользователя, по-этому из бизнес-логики почти ни чего не закэшируешь. Только самые примитивные выборки и агрегации.

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

В маркетплейсе до фига переборов. Результат выдачи зависит от десятков параметров: страны пользователя, его предыдущих поисков и покупок, текущих предложений мерчантов, стоимости доставки в страну от каждого из них, и "добросовестности" каждого из них, а также от того, в какие эксперименты попал пользователь (а в каждом эксперименте может быть ещё пяток параметров). В итоге, весь этот анализ приходится делать online в момент выдачи, т.к. от комбинаторного перемножения этих параметров ни какого кэша не хватит всё закешировать.

Какой RPS?

ох я так сразу не скажу, давно не смотрел метрики

глянул, 1250 в пике

В общем, RPS RPS-у рознь.
У нас на 10000 RPS уходит 120 ядер на API на Go, 40 ядер вспомогательного сервиса на Java, и ещё ядер 40 микросервисов на Go. Это не считая эластика, монги и редиса.
(я называю не точные цифры, т.к. я там уже не работаю, да и нельзя точные называть. Но порядок примерно такой).
И всё это раз в несколько месяцев профилируется и пытается оптимизироваться.

200-700 ms, это обычные нормальные цифры для рельсового проекта. Я долгие годы такой развивал, хайлоад, огромный портал. Сейчас так же успешно руби на другом большой проекте используем. На го только некоторые сервисы.

Всё зависит от кол-ва бизнес логики. CMS на PHP может и за 50 ms работать и выдавать 5000RPS с сервака, если ей делать ни чего не нужно практически

Сложнейшая логика. Огромный портал.

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

Все посчитано в фоне, очередями и подготовлено.