Какие библиотеки и инструменты используешь в Go

Что проверяют

Насколько вы знаете экосистему и умеете объяснять выбор, а не перечислять модные названия. Хорошим знаком считается, когда кандидат начинает со стандартной библиотеки. Следом обычно спрашивают, зачем вам фреймворк, если есть net/http, или почему sqlc, а не GORM.

Как отвечать

Разложите по слоям и к каждому пункту добавьте, почему вы это взяли:

• HTTP: net/http, с Go 1.22 стандартный ServeMux понимает методы и параметры пути (GET /users/{id}, r.PathValue("id")), поэтому chi или Gin нужны реже. Fiber построен на fasthttp и несовместим с middleware для net/http;
• база: драйвер pgx для PostgreSQL, sqlc генерирует типобезопасный код из SQL-запросов, sqlx добавляет сканирование в структуры. GORM ускоряет старт, но прячет SQL. Миграции через goose или golang-migrate;
• логи и наблюдаемость: log/slog в стандартной библиотеке с Go 1.21, OpenTelemetry для трейсов, net/http/pprof для профилирования;
• конкурентность: context для отмен и таймаутов, errgroup из golang.org/x/sync;
• тесты: testing с табличными тестами, testify для проверок, gomock из go.uber.org/mock или mockery для моков, testcontainers-go для интеграционных тестов с настоящей базой, go test -race;
• качество: go vet, golangci-lint со staticcheck внутри, govulncheck для уязвимостей в зависимостях;
• сборка: Go modules, с Go 1.24 инструменты фиксируются директивой tool в go.mod.

Покажите критерий выбора: минимум зависимостей, совместимость с net/http, живая поддержка библиотеки.

Где спотыкаются

Называют фреймворк без причины. На вопрос «зачем Gin» ответа нет, а стандартный роутер после 1.22 закрывает большинство задач.

Советуют исходный github.com/golang/mock. Он архивирован, развитие продолжено в форке go.uber.org/mock.

Не упоминают race detector и профилировщик. Для Go-разработчика это рабочие инструменты, а не экзотика, и их отсутствие настораживает сильнее, чем незнание очередного фреймворка.