Конечно не умели, в этом и суть. То, что в go у нас заработало из коробки при минимуме усилий, требовало пляски с бубнами в .net core.
Про настройки уже не помню, больше 2- лет прошло. Что-то с маршалингом JSON и поведением самого Kestrel-а.

Больше всего меня напрягало вот что: мне надо было сложить в один каталог два (на самом деле больше) executable - одно консольное, другое web service.
Так не смог. У них разные комплекты runtime DLL от core и при сваливании в общий фолдер не работает либо одна программа либо другая.
То есть 4 "микросервиса" требовали каждый своей версии runtime и занимали каждый примерно по 120 мегабайт вместо 7-8 для go.

В общем таких мелочей накопилось слишком много, чтобы с этим можно было жить без нервотрепки и ощущения, что завтра оно сломается совсем.

"Вы не любите кошек? Да вы просто не умеете их готовить." (С) автора-не-знаю.

А сколько стоило на го переехать? В человеко-годах или еще каких попугаях?

Все так. Моя задача как менеджера - решать задачи бизнеса, а не учиться готовить кошек.

Оценить точно сложно, система не очень крупная и ключевая сложность - трансляция многокритериальных запросов пользователей в SQL запросы. Это переносили как есть.
Так как С++/C# опыт на go ложится нормально (он проще синтаксически, в начале даже напрягало), цена вхождения достаточно низкая.

Плюс еще и отрефакторили накопившийся хлам, так что профит по всем направлениям.
Уже потом еще ряд плюсов такого решения всплыл, в основном в простоте интеграции со всякими Prometheus-ами и прочими готовыми для работы с экосистемой go штуками.

На мой взгляд, для web services и прочего backend экосистема go почти идеальна.
Единственный минус - стоимость рабочей силы. Очень вероятно, однако, компенсируемая производительностью участников.

Вот это место самое интересное.

Стоимость или производительность?

Производительность скорее всего сопоставима.

Субъективно - и близко нет. У go настолько шикарный tooling, что только ради него можно многое простить.
Он несколько многословен, но за счет этого лучше читается. Совокупная скорость работы команды почти наверняка выше C# и уж точно - плюсов, где бывает очень запутанный код.

Кстати, я впервые столкнулся с экосистемой, где настолько комфортно работать с unit tests, что TDD приобретает реальный смысл.

Ах да, больше нельзя попить кофейку во время компиляции 😊

Я не о конкретно написании кода, а о всем цикле - тестирование, профилирование, поиск гонок и т.д.

Вы перечислили фичи, которые в студии есть с незапамятных времен. Языки по выразительности (я художник, я так вижу!) субъективно сравнимы.
Стоимость команды гоферов выглядит дороже.
Что еще можно в качестве аргументов попробовать привести о необходимости переехать на другую экосистему?

Я не ставлю под сомнение ваше решение. Вам совершенно точно было виднее, что нужно делать.

Никто ведь не говорит о необходимости для всех

Бесспорно!

а еще Go это сейчас очень популярно в плане личного бренда.
мало кого заинтересует человек с рассказом о заумный тулинг в питоне (какой-то nerd пишет какие-то буквы руками), зато с темой про статический анализ кода в Go можно заочно получить авторитет эксперта и приглашения выступить в кучу мест.

Да, это все мое субъективное ощущение. Я VS пользуюсь с 98-й версии, но речь скорее не о IDE, а об усилиях, которые нужно затратить для полноценного доступа к инструменту; в том числе из CI.
Я не очень себе представляю, как запустить в контейнере C#-ные unit tests или линтеры и сколько усилий это потребует.

У нас еще важным аргументом за переезд была модель параллелизма.
Легковесные треды ака горутины - очень прозрачный и легко воспринимаемый механизм. Не без странностей, но проще async/await.

Что касается стоимости, то есть два соображения:
1. университеты "увидят" go и через несколько лет мы начнем получать выпускников с готовым знанием языка и background в CS одновременно.
2. возможно, что в какой-то мере эта стоимость обусловлена более масштабными задачами и бОльшей ответственностью, чем для других технологий.

Хайп вокруг go растет, это факт.
Но нельзя исключать, что это следствие его популярности. В конце концов, k8s, docker и prometheus не на C# написаны 😊

посмотрим, конечно, потому что ситуацию интересно с разных сторон рассматривать https://r3code.livejournal.com/239918.html

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

Для go есть прикольная штука golangci-lint, вызывающая сразу пачку линтеров, прием можно выбирать какие включить какие нет.
По умолчанию включено около 10-ка из 50+ доступных из коробки.
И оно местами прямо очень хорошо помогает против опечаток и глупых косяков.

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

упомянутые исследования, этот тезис, мягко говоря, не подтверждают:
- есть, и весьма распространены классические ошибки
- есть , и весьма распространены, и ошибки, присущие CSP-модели go