Библиотека Go разработчика

🧑‍💻 Контекст + канал = контролируемая отмена

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

Вместо того чтобы ждать только данных из канала, горутина одновременно слушает сигнал отмены из контекста. Как только кто-то вызывает cancel() или истекает таймаут — ctx.Done() закрывается, и все горутины, которые его слушают, корректно завершаются.

Это работает на любой глубине вложенности: отменили корневой контекст — сигнал получат все дочерние.

Реальный пример: HTTP-запрос с отменой

func fetchData(ctx context.Context, url string) ([]byte, error) {
    req, err := http.NewRequestWithContext(ctx, "GET", url, nil)
    if err != nil {
        return nil, err
    }

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return nil, err // ctx.Err() если отменили
    }
    defer resp.Body.Close()

    return io.ReadAll(resp.Body)
}

// Вызов с таймаутом:
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel() // всегда defer cancel()!

data, err := fetchData(ctx, "https://api.example.com/data")

Если сервер не ответил за 3 секунды — запрос автоматически отменяется. Никаких висящих горутин.

Context или просто close(ch)

• Используйте close(ch) когда хотите сигнализировать, что данные закончились — один продюсер завершил работу, консюмеры это видят.

• Используйте context когда нужна отмена извне — пришёл сигнал остановиться, истёк таймаут, пользователь нажал cancel. Контекст распространяется вниз по дереву вызовов сам.

• Они не конкурируют — часто используются вместе: канал несёт данные, контекст несёт намерение остановиться.

Главные правила:

defer cancel() сразу после создания контекста — без исключений. Передавайте ctx первым аргументом в функцию. Не кладите context внутрь структур, это спорно, но большинство стайлгайдов против. Проверяйте ctx.Err() после долгих операций.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep

🔄 go-testdeep — большое обновление

Вышел релиз go-testdeep v1.15.0 — одной из библиотек для глубокого сравнения данных в тестах на Go. И в этот раз изменений особенно много.

Главное: библиотека теперь без зависимостей

go-testdeep стал полностью dependency-free. Авторы встроили go-spew напрямую. Меньше go.sum, меньше проблем с совместимостью.

Новые операторы

List — простая и лёгкая альтернатива массивов и слайсов для сравнения в строгом порядке:

td.Cmp(t, []int{1, 9, 5}, td.List(1, 9, 5))

Sort — сортирует слайс перед сравнением. Поддерживает сложные ключи, вложенные поля и даже использование внутри JSON-оператора:

td.Cmp(t, got, td.Sort("-props[priority]", []A{p34, p23, p12}))

Sorted — просто проверяет, что слайс уже отсортирован:

td.Cmp(t, aSlice, td.Sorted())
td.Cmp(t, aStructSlice, td.Sorted("-FieldName")) // по убыванию

Must, Must2, Must3 — меньше бойлерплейта

Раньше нужно было писать две строки на обработку ошибки. Теперь одну:

// было
val, err := myfunction()
td.Require(t).CmpNoError(err)

// стало
val := td.Must(myfunction())

Если вы пишете тесты на Go и ещё не пробовали go-testdeep — самое время.

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoLive

🤩 Топ-вакансий для Go-разработчиков за неделю

Senior Golang developer (Gamedev) — удалёнка

Junior Go-developer — от 160 000 ₽, удаленно

Senior Go Developer — 406 000 ₽, удаленно

➡️ Еще больше топовых вакансий — в нашем канале Go jobs

🐸 Библиотека Go-разработчика

#GoWork

Go на бэкенде, Python в «мозгах»

Как подружить высокопроизводительный Go-бэкенд с AI-агентами? В 2026-м это стандартная задача. Мы обновили курс «Разработка AI-агентов», сделав упор на архитектуру и интеграцию в продакшн.

Что полезного для Go-разработчика?

🔹 Архитектура системы. Асинхронное взаимодействие, очереди задач, управление состоянием агентов (`State Management`).

🔹 Экономика и ресурсы. Контроль токенов, кэширование, роутинг запросов — всё, что нужно для HighLoad AI.

🔹 Интеграция. Как встроить RAG и агентные цепочки (`LangGraph`) в существующую микросервисную архитектуру.

🔹 Надёжность. Трассировка ошибок, метрики и runbook для восстановления.

Стартуй сейчас! Получи базу знаний сразу после покупки.

🎟 Промокод Agent — скидка 10 000 ₽ (до 28 февраля).

👉 Строим архитектуру AI-сервисов

🧑‍💻 Приоритизация каналов в Go

select выбирает кейс случайно, если готовы несколько каналов. Звучит просто, но на практике это боль: срочное сообщение может ждать в очереди, пока обрабатывается менее важное.

Разберём, как это починить:

select {
case msg := <-urgent:
    handle(msg)
case msg := <-normal:
    handle(msg)
}

Никаких гарантий, что срочное обработается первым.

Решение: двойной select

for {
    // Сначала пробуем срочный канал
    select {
    case msg := <-urgent:
        handle(msg)
    default:
    }

    // Потом общий
    select {
    case msg := <-urgent:
        handle(msg)
    case msg := <-normal:
        handle(msg)
    }
}

Первый select с default не блокируется — он мгновенно проверяет, есть ли что-то срочное. Если да — обрабатываем и идём на следующую итерацию. Если нет — падаем во второй select и ждём любой из каналов.

Главная опасность — голодание. Если urgent забит сообщениями постоянно, normal не получит ничего никогда.

Защита — счётчик или таймер:

normalTimeout := time.After(5 * time.Second)

for {
    select {
    case msg := <-urgent:
        handle(msg)
    default:
    }

    select {
    case msg := <-urgent:
        handle(msg)
    case msg := <-normal:
        handle(msg)
    case <-normalTimeout:
        // Принудительно даём слово normal
        msg := <-normal
        handle(msg)
        normalTimeout = time.After(5 * time.Second)
    }
}

Простота против гибкости. Согласны с таким выбором или предпочли бы встроенный механизм?

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep

⚙️ Библиотека для управления долгоживущими процессами

Небольшая, но элегантная zero-dependency библиотека для Go, которая решает классическую задачу: как правильно запустить несколько фоновых процессов и корректно их завершить.

В основе лежит один интерфейс:

type Runnable interface {
    Run(context.Context) error
}

Завершение работы управляется через отмену контекста — всё предсказуемо и идиоматично.

Главная фича — менеджер с двухуровневой иерархией. Cначала останавливаются процессы: HTTP-серверы, воркеры, задачи по расписанию; и только потом сервисы: очереди, БД, метрики.

Менеджер сам является Runnable — значит менеджеры можно вкладывать друг в друга для независимого управления жизненным циклом.

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

Docker и Kubernetes: основы разработки под облачную инфраструктуру

Курс для тех, кто хочет держать свой стэк и знания актуальными и глубоко разбираться, как устроены Docker, Kubernetes, и современная облачная инфраструктура в целом.

🌐 Чему вы научитесь:

🤩 Создавать облачную инфраструктуру «с нуля» управление и конфигурация серверов с Terraform, Ansible, cloud‑init
🤩 Уверенно работать с Docker: Dockerfile, слои, кэш, многоступенчатые сборки, реестры, безопасность, air‑gapped
🤩 Проектировать многоконтейнерные приложения: паттерны Sidecar, Ambassador, Adapter, проверки (liveness/readiness), DaemonSet и поды
🤩 Настраивать сеть и балансировку в Kubernetes
ClusterIP, Services, Ingress, MetalLB, TLS/SNI, сервис‑меши (Istio)
🤩 Организовывать хранение данных: PersistentVolumes / PVC, StorageClasses, резервное копирование. Упаковка в Helm и поддержка через Operator

🥸 Кто мы: R&D-центр Devhands. Автор курса — Николай Ихалайнен, эксперт по СУБД и бекенду (ex-Percona), со-основатель MyDB, энтузиаст открытого ПО.

🗓 Старт курса: 25 февраля, 6 недель обучения.
Изучить программу и записаться можно здесь.

Ждем вас!

Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzqvMkFkG

🛠 Cобираем результаты от множества горутин

Fan-In — паттерн, обратный Fan-Out. Несколько горутин производят данные независимо, а один канал собирает всё воедино. Это финальная часть пайплайна.

Каждый воркер пишет в свой канал → merge-функция сливает все каналы в один → потребитель читает из одного места, не зная сколько источников было.

Ключевая идея

На каждый входящий канал запускается своя горутина-переливщик. Все они пишут в общий merged. Когда все источники иссякли — merged закрывается:

func merge(channels ...<-chan int) <-chan int {
    merged := make(chan int)
    wg := sync.WaitGroup{}

    pipe := func(c <-chan int) {
        defer wg.Done()
        for v := range c {
            merged <- v
        }
    }

    wg.Add(len(channels))
    for _, c := range channels {
        go pipe(c)
    }

    go func() {
        wg.Wait()
        close(merged)
    }()

    return merged
}

Также можно отменять через контекст:

pipe := func(c <-chan int) {
    defer wg.Done()
    for {
        select {
        case v, ok := <-c:
            if !ok {
                return
            }
            merged <- v
        case <-ctx.Done():
            return
        }
    }
}

Без этого горутины-переливщики зависнут, если потребитель неожиданно отвалится.

Три правила Fan-In:

— Каждый источник сам закрывает свой канал
— close(merged) только после wg.Wait()
— Горутина с wg.Wait() всегда отдельная, иначе дедлок

Fan-Out + Fan-In вместе = полный пайплайн

Fan-Out раздаёт задачи, Fan-In собирает ответы. Между ними — изолированные воркеры без общего состояния.

Порядок результатов не гарантирован — это цена параллельности. Если порядок важен, нужно добавлять индекс к каждому результату и сортировать после сбора.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep

👨‍💻 От фронта к Go

Представьте разработчика с 4+ годами на React/React Native. Типовой рабочий цикл выглядит примерно так:

сгенерировать UI-компонент → добавить JS/TS логику → повторить

В этой модели UI — главный герой. Всё остальное — вспомогательный шум. Указатели? Управление памятью? Конкурентность? За вас давно всё решили. Фронтенд-разработчик рассказал у себя в блоге про переход на Go, потому что он устал от шума в голове.

Фронтенд-стек агрессивно абстрагирует детали. Это удобно — и это ловушка. Указатели просто не существуют в JS. Переменные — либо примитивы, либо ссылки, и вся эта механика скрыта за синтаксисом. Конкурентность — это async/await и промисы. Что происходит под капотом event loop — можно годами не знать. Зависимости растут бесконтрольно. В среднем React-проекте node_modules — это несколько тысяч пакетов.

Почему Go — это смена мышления, а не просто новый синтаксис

Go возвращает программиста к базовым вещам:

1. Указатели — снова явные

func increment(n *int) {
    *n++
}

Вы снова думаете о том, передаёте ли значение или адрес. Это не баг — это фича, которая возвращает контроль.

2. Стандартная библиотека вместо npm

В Go принято сначала спросить: «есть ли это в stdlib?» HTTP-сервер, JSON, криптография, конкурентность — всё это уже там. Импорт сторонней библиотеки — осознанное решение, а не рефлекс.

3. Горутины вместо колбэков

Модель конкурентности в Go — одна из самых элегантных в индустрии. Каналы, горутины и планировщик дают контроль, которого у async/await нет по определению.

4. Ошибки как значения

result, err := doSomething()
if err != nil {
    return err
}

Никаких try/catch, которые легко пропустить. Ошибка — это часть сигнатуры функции. Обработка явная.

Разработчик, который переходит с React на Go, начинает по-другому думать об архитектуре всего стека:

— понимает, как работает сеть
— начинает читать про алгоритмы и структуры данных — они снова актуальны
— видит, как строятся серверы, парсеры, CLI-инструменты

Go часто описывают как «Cи с удобным синтаксисом» — и это точное ощущение для тех, кто давно не спускался ниже компонентного уровня.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoLive

🛠 Распределяем работу между воркерами

Fan-Out — паттерн конкурентности, когда один источник данных распределяет задачи по нескольким воркерам параллельно. Это позволяет обрабатывать данные быстрее, используя все ядра процессора.

Как это выглядит схематично

┌─────────────┐
│ источник │
└──────┬──────┘
│
┌────────┼────────┐
▼ ▼ ▼
[worker1] [worker2] [worker3]
│ │ │
└────────┼────────┘
▼
[ результат ]

Один канал на входе → несколько горутин читают из него → результаты собираются вместе.

Ключевая идея:

Горутины конкурентно читают из одного канала. Go гарантирует, что каждое значение получит ровно одна горутина — никаких гонок, никаких дублей:

func worker(id int, jobs <-chan int, results chan<- int, wg *sync.WaitGroup) {
    defer wg.Done()

    for j := range jobs {
        results <- j * j
    }
}

func main() {
    jobs := make(chan int, bufSize)
    results := make(chan int, bufSize)

    var wg sync.WaitGroup

    // стартуем воркеров
    for i := 0; i < numWorkers; i++ {
        wg.Add(1)
        go worker(i, jobs, results, &wg)
    }

    // отправляем задачи
    for i := 0; i < numJobs; i++ {
        jobs <- i
    }
    close(jobs)

    // отдельная горутина ждёт воркеров и закрывает results
    go func() {
        wg.Wait()
        close(results)
    }()

    // читаем результаты
    for r := range results {
        fmt.Println(r)
    }
}

Жизненный цикл:

1. Источник кладёт задачи в jobs
2. N воркеров читают jobs конкурентно
3. После jobs закрыт → воркеры завершаются → wg.Done()
4. WaitGroup → close(res)
5. main читает все результаты из res

Когда применять:

— CPU-интенсивные задачи: сжатие, шифрование, парсинг
— I/O-bound задачи с независимыми запросами
— Параллельная обработка батчей данных

Когда НЕ применять:

— Задачи зависят друг от друга
— Нужен строгий порядок результатов
— Слишком лёгкие задачи, когда накладные расходы > выгода

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep