Чтобы ваши агенты не были такими глупыми приходите на наш курс по разработке AI-агентов

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

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

#GoGiggle

🤖 Контрольный слой для продовых AI-систем

Когда компания внедряет LLM в продакшн, возникает проблема: как контролировать то, что уходит к OpenAI или Anthropic? Как убедиться, что модель не получит персональные данные клиентов или не выполнит SQL-инъекцию через подключенную базу данных?

AxonFlow решает эту задачу, размещаясь между вашим приложением и LLM-провайдером. Платформа проверяет каждый запрос на соответствие политикам безопасности ещё до того, как он достигнет модели.

Cистема анализирует не только входящие запросы, но и ответы от подключённых баз данных через MCP-коннекторы. Если в ответе обнаружены признаки эксплуатации уязвимостей, данные не передаются дальше.

Исходный код открыт, разработка ведётся на Go с покрытием тестами.

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

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

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

#GoToProduction

✏️ Разные версии — разный вывод

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

Попробуйте разгадать какая версия изменит этот код и в чём конкретно будет разница.

Ответ: здесь и здесь

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

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

#ReadySetGo

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

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

#GoGiggle

🤡 Игра против тёмных паттернов

Отдохнём в эту субботу от бэкенда и поиграемся с фронтом.

Тёмные паттерны — не только UX-грех, но и проблема для фронтенда. Наткнулись на игру, в которой нужно уворачиваться от всех попыток выманить у вас деньги, кликая по правильным кнопкам «Skip».

➡️ Пропустить платные услуги

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

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

#GoGiggle

🔄 GoRL v2.0.0

GoRL — это библиотека для ограничения запросов на Go, которая недавно получила мажорное обновление v2.0.0.

GoRL поддерживает четыре алгоритма ограничения и работает как с in-memory хранилищем, так и с Redis для распределённых систем.

Что нового

• Lock-free in-memory хранилище

• Автоматическая сборка мусора для истёкших ключей

• Context-aware API

• Zero-config middleware для всех популярных фреймворков

• Оптимизированные алгоритмы

➡️ Репозиторий | Release Notes

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

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

#GoLive

💡 Дайджест недели

Главный фокус на Go 1.26, но помимо этого были события.

— Go 1.26

— ИИ хотел завалить разработчиков JetBrains

Чат-бот во время пожарной тревоги ответил в Slack, что не стоит беспокоится и тревога учебная. Тревога не была учебной.

— Оптимизации кода + бенчмарк

— Бустим продуктивность

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

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

#GoLive

👨‍💻 TicTacToe SSH

Крестики-нолики в реальном времени, запускаемые прямо в терминале через SSH.

Отличный пример для первого проекта: SSH как протокол доступа, Go для backend-логики, Firebase для состояния, Bubble Tea для интерфейса

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

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

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

#GoLive

⚙️ Конвейер с данными

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

➡️ Классический конвейер состоит из трёх типов компонентов

Генератор — создаёт данные и отправляет их в канал. Это источник данных, который не принимает входящих каналов, только возвращает исходящий.

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

Потребитель — принимает финальные данные из канала и использует их: выводит, сохраняет, агрегирует. Это конечная точка конвейера.

Рассмотрим обработку потока чисел: генерация → фильтрация чётных → возведение в квадрат.

package main

import "fmt"

// Generator: генерирует числа от 1 до n
func generate(n int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for i := 1; i <= n; i++ {
            out <- i
        }
    }()
    return out
}

// Processor 1: фильтрует только чётные числа
func filterEven(in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for num := range in {
            if num%2 == 0 {
                out <- num
            }
        }
    }()
    return out
}

// Processor 2: возводит числа в квадрат
func square(in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for num := range in {
            out <- num * num
        }
    }()
    return out
}

// Consumer: выводит результаты
func main() {
    // Строим pipeline
    numbers := generate(10)
    evens := filterEven(numbers)
    squares := square(evens)
    
    // Потребляем результаты
    for result := range squares {
        fmt.Println(result) // 4, 16, 36, 64, 100
    }
}

➡️ Зачем нужен конвейер

Конкурентность — все этапы работают одновременно. Пока генератор создаёт следующее число, обработчик уже обрабатывает предыдущее, а потребитель выводит готовый результат.

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

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

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

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

#GoDeep

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

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

#GoGiggle

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

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

👨‍💻 От фронта к 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