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

В Go вам придется или самому собрать фреймворк из готовых либ, или написать свой. Вот и вся сложность. Если нет проблем с уровнями абстракции и пониманием слоев в архитектуре ПО, сложностей возникнуть не должно. Но да, многое придется делать ручками.

Более выразительно для вас != Более выразительно для всех. В том и проблема гибких языков - на них каждый всегда свою библиотеку классов пишет, думаете почему? Потому что другим легче вашу выразительность с нуля переписать, чем разбираться и принимать идеологию

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

гибкость, богатство и выразительность - почти ортогональные вещи

го, правда, не гибкий, не выразительный, и не богатый.

Главное, чтобы этот сахар хоть как-то апрувился при компиляции. Типчиками например. Иначе это боль.

😕 Выходит Ruby идеальный для этого язык?

более выразительно для команды, которая разработала и продолжает поддерживать сервис

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

Руби, в принципе, идеальный язык)

Ну, я пошёл

😂 Слишком идеальный для нашего тленного мира судя по личному опыту.

да, и мы видим тому подтверждения в реальности. RoR - это нереально круто.

с производительностью, правда, проблемы, но это уже другая история

ну вообще да, за счёт чего в своё время выстрелил

Я вот вижу 2 варианта в теории. в практике таких сложностей не встречал.
Есть допустим какой-то слой с бизнес-логикой, назовем его доменный слой.
Первый вариант в одной монорепе сделать. Второй вариант - пакет с бизнес-логикой вынести в отдельный пакет в отдельной репе, и в остальных сервисах использовать его? Какой лучше?

другое дело что у рубей есть другие недостатки, которые его потихоньку добивают

я лично люблю мультирепу.

но и в монорепе научился жить

У меня не хватило мозгов к сожалению оценить. Не хватает сил учить еженедельно новый DSL (При этом как правило написаный на коленке и без документации). А именно так я бы свой опыт работы с Ruby и RoR и описал. 😕

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

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

ну да, а скорость разработки и прототипирования и достигается за счёт всё того же сахара и выразительности