Go vs Python: когда стоит брать Go для backend

Когда команда упирается в потолок производительности Python, первый вопрос — переписывать ли горячие участки на Go. Я работал с обеими экосистемами в продакшене и ниже разберу, где Go действительно решает, а где это лишний слой сложности.

Откуда вообще взялся Go

Go создан в Google в 2009 году командой Роберта Гризмера, Роба Пайка и Кена Томпсона. Задача была конкретная: язык для серверов, который компилируется быстро, выполняется быстро и не требует от инженера лекций по типам памяти. Изнутри Google они страдали от долгих сборок C++ и многословности Java — Go родился как ответ на эту боль.

К 2026 году Go — стандарт для облачной инфраструктуры. Docker, Kubernetes, Terraform, etcd, CockroachDB, InfluxDB, Prometheus — всё это написано на Go. Если вы пользуетесь современным CNCF-стеком, вы пользуетесь Go ежедневно, даже если сами не пишете на нём ни строчки.

Что делает Go быстрым

Три ключевые вещи отличают Go от Python:

Компиляция в нативный машинный код. Go-программа — это один статический бинарник без рантайма-интерпретатора. Запустилась — сразу работает на полной скорости.

Goroutines и каналы. Лёгкие потоки исполнения, по умолчанию 8 KB стека (vs 1 MB у OS-потока). На одном инстансе спокойно крутятся сотни тысяч горутин. Для I/O-нагруженных систем (API, прокси, websocket-серверы) это огромный выигрыш.

Жёстко типизированный язык с компиляцией. Половина ошибок Python-кодовой базы — AttributeError, KeyError, TypeError в рантайме — в Go ловится при сборке. Меньше падений в продакшене, чем при equivalent Python-проекте.

Реальные цифры из моей практики

На одном проекте у клиента стоял Django + Celery, обрабатывающий ~500 событий в секунду от мобильных клиентов. Чтобы выдерживать пики до 5000/сек, нужно было либо горизонтально масштабировать на 10+ инстансов, либо переписать горячий путь.

Я вынес обработчик событий в отдельный Go-сервис — 600 строк кода. Один инстанс на 2 vCPU держит 3000 событий в секунду без напряжения. P95-латенция упала с 180 мс до 12 мс.

Счёт за инфраструктуру упал с $480 до $90 в месяц. Сервис на Go окупился за первый месяц.

Когда Go — правильный выбор

// Типичный hot-path сервис на Go
package main

import (
    "encoding/json"
    "net/http"
)

func handleEvent(w http.ResponseWriter, r *http.Request) {
    var ev Event
    if err := json.NewDecoder(r.Body).Decode(&ev); err != nil {
        http.Error(w, err.Error(), 400)
        return
    }
    // Каждый запрос — в отдельной горутине автоматически
    go process(ev)
    w.WriteHeader(204)
}

Берите Go когда:

• High RPS с низкой латентностью: API-шлюзы, прокси, real-time-сервисы
• Параллельность важнее, чем библиотеки: рутины бьют любую async/await на синтаксисе
• Нужен один статический бинарник для деплоя без зависимостей
• CPU-bound нагрузка: парсинг, шифрование, числовая обработка
• Микросервисы с минимальным memory footprint (40-80 MB на инстанс)

Когда Python всё ещё лучший выбор

# То, что в Go писать в 5 раз дольше
df = pd.read_sql("SELECT * FROM events WHERE date > %s", conn, params=[since])
df["bucket"] = pd.cut(df["amount"], bins=[0, 100, 1000, 10000])
result = df.groupby(["bucket", "category"])["amount"].agg(["sum", "mean", "count"])

Питон выигрывает по продуктивности там, где:

• CRUD-приложения с админкой: Django делает за день то, что на Go делается за неделю. Я не буду переписывать Django Admin на Go ради 30% прироста — теряю гораздо больше во времени разработки.
• ML и обработка данных: pandas, numpy, scikit-learn, PyTorch. На Go этой экосистемы нет, и появится она нескоро.
• Скриптовая автоматизация и интеграции: «спарсить CSV → положить в S3 → отправить уведомление» — это 30 строк Python и 200 строк Go.
• Команда из 1-3 человек на старте: продуктивность важнее производительности. Сначала запустите MVP, потом оптимизируйте узкие места.
• Прототипы и эксперименты: Jupyter, REPL, динамическая типизация — это инструменты быстрых итераций.

Гибридный подход — обычно правильный

Я почти никогда не выбираю «или-или». Типичная архитектура зрелого проекта:

• Django + DRF держит админку, бизнес-логику, CRUD, импорт данных, биллинг
• Go-сервисы обрабатывают горячие пути: вебхуки, real-time-уведомления, агрегация событий, geo-поиск
• Между ними — RabbitMQ или Redis Streams + защищённые HTTP-ручки

Один проект — два технологических стека. Каждый делает то, в чём он сильнее. Это не overengineering — это инженерное распределение ролей.

Что выбрать для нового проекта

Если запускаете SaaS с нуля и пока не знаете, где будут узкие места: берите Python (Django + FastAPI). Из 100 проектов 90 не уткнутся в производительность Python никогда. Из оставшихся 10 — половина решается оптимизацией БД и кешем, а не сменой языка.

Если строите real-time-инфраструктуру (биржу, мессенджер, IoT-шлюз): берите Go сразу. Тут переписывать с Python будет дорого.

Итог

Go — мощный инструмент для конкретных задач. Не «замена Python», а соседний по стеку язык. Знание обоих делает вас в разы более универсальным инженером, чем фанатичная преданность одному.

В моих проектах граница простая: пользовательские формы, админки, отчёты, интеграции — Python. RPS > 1000, p95 < 50 мс, gRPC, websocket-фанаут — Go. И эта граница сдвигается в сторону Go только когда есть конкретная причина.

ПоделитьсяTelegramWhatsApp