Какие задачи обычно решаются с помощью Go

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

Понимаете ли вы, почему Go выбирают для определённых задач, а не просто перечисляете ниши. Хороший ответ связывает задачи со свойствами языка и честно называет, где Go не лучший выбор. Следом часто спрашивают, что вы сами на нём писали.

Как отвечать

Основные направления и почему там Go:

• сетевые сервисы и API: HTTP и gRPC-сервисы, микросервисы. Стандартный net/http готов к продакшену, горутина на соединение стоит несколько килобайт стека, а планировщик сам раскладывает горутины по потокам ОС;
• облачная инфраструктура: на Go написаны Kubernetes, Docker, etcd, Prometheus, Terraform. Отсюда богатая экосистема клиентов и операторов для Kubernetes;
• прокси и сетевые утилиты: обратные прокси вроде Caddy и Traefik, VPN, сетевой мониторинг;
• CLI-утилиты: один статический бинарь без зависимостей, кросс-компиляция через GOOS и GOARCH, библиотека cobra для команд;
• конвейеры обработки: консьюмеры Kafka, агрегация логов и метрик, фоновые воркеры, где нужны конкурентность и предсказуемое потребление памяти.

Свойства, на которые стоит сослаться: быстрая компиляция, простой язык, который легко читать в большой команде, встроенные go test, pprof и детектор гонок, сборщик мусора с короткими паузами.

Где Go слабее: машинное обучение и анализ данных (там экосистема Python), настольные GUI, задачи с жёсткими требованиями к задержкам без пауз GC, где берут Rust или C++. Дженерики появились в Go 1.18, но сложные абстракции по-прежнему выражаются менее удобно, чем в языках с богатой системой типов.

Закончите своим примером: какой сервис вы писали, какая была нагрузка и чем Go помог или мешал.

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

Говорят, что Go «быстрый как C». У него рантайм и сборщик мусора, в вычислительных задачах он обычно медленнее C и Rust, зато проще в разработке сетевых сервисов.

Отвечают одним словом «микросервисы» и не объясняют, какие свойства языка для этого важны.

Не могут назвать, где Go не подходит. Без этого ответ звучит как реклама, а не как инженерное суждение.