Разберите конкретный случай: симптом, версия Go, диагностика, причина, исправление и проверка результата. Возможные темы — лишние аллокации, удержание памяти, утечки горутин, гонки и блокировки. Не называйте отсутствие generics текущей проблемой языка и не приписывайте любой сбой приложения самому Go.
С какими проблемами Go вы сталкивались в production?
Как отделить реальный опыт диагностики от общих недостатков языка и давно устаревших ограничений.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Выберите проблему, которую действительно расследовали. Список общеизвестных ограничений языка не заменяет практический опыт, а утверждения о старых версиях могут вводить в заблуждение.
Возможные направления — только как подсказки для выбора собственного случая:
- увеличение числа горутин из-за зависания на канале или незавершённого запроса;
- удержание объектов в кэше или больших буферов;
- высокие затраты на аллокации и GC;
- гонка при совместном доступе к состоянию;
- конкуренция за блокировку;
- несовместимое изменение зависимости или ошибка сборки.
Опишите симптом и инструмент, который помог локализовать причину. Профили CPU, heap, goroutine, block и mutex отвечают на разные вопросы; выбирать их нужно по гипотезе. Возможности и стоимость сбора описаны в руководстве по диагностике Go.
Race detector обнаруживает гонки на реально выполненных путях, а не доказывает отсутствие всех логических race condition. Исправление должно устранять неправильное владение данными или синхронизацию, а не просто скрывать сообщение инструмента.
Покажите, как сравнили поведение до и после изменения и не ухудшили другой показатель. Например, пул буферов может уменьшить аллокации, но увеличить удерживаемую память.
Исторические трудности, такие как отсутствие generics до Go 1.18, уместны только с явным периодом. Не представляйте их свойствами актуального Go. Если production-опыта пока нет, прямо обозначьте это и обсуждайте учебный пример без выдуманного инцидента.