Стандартная ситуация в небольших компаниях семейного типа. Зарплаты знает только генеральный директор и рекрутер. Тимлид лишь проверяет знания.

про .net core.

Да, удобнее собирать каждый exe в отдельный каталог со своими зависимостями.
если хотите чтобы все лежало вместе, то надо желательно завести отдельный nuget репозиторий,в котором каленым железом выжигать дубли пакетов (чтобы была только одна версия).
Тогда будет согласованность.

И конечно на build сервере не забыть вычистить темповые каталоги с пакетами.

У нас разброс компонентов по каталогам ощутимо усложнит бы конфигурацию или потребовал какого-то service discovery инструмента, который бы знал, что и где лежит. Связано это с устройством updates на лету.

У нас разброс компонентов по каталогам ощутимо усложнит бы конфигурацию или потребовал какого-то service discovery инструмента, который бы знал, что и где лежит. Связано это с устройством updates на лету.

У нас разброс компонентов по каталогам ощутимо усложнит бы конфигурацию или потребовал какого-то service discovery инструмента, который бы знал, что и где лежит. Связано это с устройством updates на лету.

а сколько по времени занял переход на Го? Не было ли вопросов со стороны акционеров/инвесторов/владельцев? Как защищали решение?

Примерно 2-2.5 месяца, сервис не слишком большой. Решение я принимал "в одно рыло" особо ни с кем не советуясь, так как за результат тоже отвечаю сам. Были переработки, но не запредельные.

и как разработчикам Го? после С++ и c# (хотя в шарпе,я так понял, компетенции были хуже,чем по ++)

в дедлайны уложились? не совсем понятна картина: есть ли над вами кто может спросить почему так долго и дорого? или вы последняя инстанция?

Дисклеймер: все будет очень субъективно. Ядро команды - С++-ники без очень глубокого .net опыта, хотя с технологией работали еще со времён .net 2.0, поэтому часть проблем вам могут показаться странными. Разрабатываемая система – специализированная аналитическая система, архитектурно – монолит с небольшими сервисами рядом и своей системой оркестрации и мониторинга.
Минусы .net core:
Большое количество мелких и не очень проблем со сборкой и развертыванием. В теории они могут собирать все в один executable, но на практике добиться его 100% работоспособности нам не удалось (валился в случайных местах), поэтому windows-решение выглядело как 130 мегабайт и пара сотен DLL. Сборки из IDE, MS Build и родным CLI от .net core порождают разные бинарники из одного и того же набора исходников, причем в третьем случае – не всегда работоспособные.
В один каталог не удается развертывать два executable, а нам это технологически было очень удобно. Происходит это из-за того, что вышеупомянутый «комплект» из  120-130 Мб DLL разный в зависимости от того, какие классы .net используются. В результате в сравнении с Go бинарный размер решения отличается ровно на порядок при том же самом функционале.
При накатывании updates на Visual Studio незаметным образом меняются и DLL от .net core, что тоже порождает свои чудеса – за этим надо сделать чтобы не получить несовместимый комплект «мира».  У нас есть система update решения прямо на лету (5-7 секунд downtime) и эти чудеса порождали отдельный напряг раз в месяц-полтора.
Проблема с драйверами: Microsoft толкает всех в свой ORM (Entity Framework), а у нас есть свои, довольно тонкие, обвязки вокруг СУБД, в результате чего включить в комплект развертывания low level драйвер не получается и его надо отдельно ставить. Для Windows это ODBC, для Linux какой-то костыль, с которым мы так до конца и не справились, увы.
.net core достаточно высокоуровневый и абстрактный, то есть для того, чтобы что-то поменять на низком уровне или покопаться в кишочках pipeline, нужна магия, в свою очередь требующая «курения» документации, а то и исходников самого core. От «вау как круто» в первые месяцы это свелось к «б%я, но почему именно так?» на более зрелых этапах разработки.
Оно кушает память не всегда понятным образом. Не Java конечно, но разница с Go все равно получилась от 50 до 200-300%.
Плюсы .net core:
Безусловно, главный плюс – это сам C#, комфортный и современный язык. Новые версии Visual Studio (desktop, не Code) очень хороши.
Плюсы Go
Zero dependency binary – это просто прелесть, проблем нет вообще, скопировал единственный executable на любую систему и оно поднялось. После core – небо и земля, примерно 100% проблем с deployment были устранены.
Кросс-компиляция – один ключик, а дальше смотри предыдущий абзац.

Шикарный tooling из коробки, от unit testing и benchmarking до linter и formatter  – тут можно много говорить, спрашивайте, если интересны подробности.
Порог вхождения для developers в конкурентное программирование выглядит ниже. Все понимают что канал – это банальная очередь с mutex, но пользоваться ими комфортно. Горутины и вот это все.
Минусы Go
Такого убогого языка я не видел со времен Fortran 77, нет даже тернарного оператора. Есть ряд неочевидных «подводных грабель», на разборки с которыми уйдет день-два своими силами или прочтение пары статей.  Обратная сторона – любой middle из мира С++ или C# будет радостно кодить на go через пару дней после выдачи документации.

Хм, а в .net нет аналогов fat jar? В java все собрать в один большой файл нет проблем.
Может, вам вместо .net надо было на kotlin переходить, там нет указанных проблем вообще

Да и если писать нормально, то не будет там память улетать.