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

👨‍💻 Маленький слайс держит большой массив

Классическая ловушка памяти, которую многие не замечают.

buf := make([]byte, 10<<20)  // 10 MB буфер  
small := buf[:100]           // берём 100 байт  
store(small)                 // сохраняем  

Кажется, что small = 100 байт, но на самом деле он держит все 10 МБ.

Почему так происходит

Слайсы — это не копия данных, а три числа:

• Указатель на начало массива
• Длина (len) — сколько элементов видно
• Ёмкость (cap) — размер исходного массива

Когда делается buf[:100]:

• Создаётся новый slice
• Но он указывает на тот же самый базовый массив
• GC видит, что массив используется, и не удаляет его

Правильное решение:

// Вариант 1: явное копирование
smallCopy := make([]byte, 100)
copy(smallCopy, buf[:100])
store(smallCopy) // теперь 10 MB освободится

// Вариант 2: slices.Clone (Go 1.21+)
import "slices"
smallCopy := slices.Clone(buf[:100])

Не баг, а фича — просто нужно знать, как работают слайсы.

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

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

#GoDeep

🏭 Трудоголизм — новая база

Эпоха офисных плюшек и корпоративных психологов закончилась быстрее, чем мы думали. Wellbeing-программы больше не окупаются, а на место одного выгоревшего сеньора приходит 200 резюме.

Компании решили, что выгорание — это не баг менеджмента, а побочный эффект, почему?

➡️ Читайте в статье

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

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

Go Roadmap: масштабирование мультиагентных систем

Для `Go`-разработчика ИИ-агенты — это вызов в области параллелизма, производительности и надёжности оркестрации систем.

Этапы погружения:

— изучение механик планирования и Tool Calling в ИИ-системах;

— реализация эффективного взаимодействия между агентами в реальном времени;

— деплой автономных агентов в высоконагруженных средах;

— оптимизация затрат ресурсов при работе с LLM.

Курс «Разработка ИИ-агентов» поможет вам освоить методологию создания автономных модулей для бизнеса.

Узнать больше о курсе

Акция «3 в 1»: купите один курс — два других получите бесплатно до 19 января.

🤨 Когда использовать sort.Sort, а когда sort.Stable

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

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

Нестабильный пример:

package main

import (
    "fmt"
    "sort"
)

type Product struct {
    Name  string
    Price int
}

func main() {
    products := []Product{
        {"Laptop", 1000},
        {"Phone", 500},
        {"Tablet", 300},
        {"Monitor", 500},
    }

    // Сортируем только по цене
    sort.Slice(products, func(i, j int) bool {
        return products[i].Price < products[j].Price
    })

    fmt.Println("sort.Slice (нестабильная):")
    for _, p := range products {
        fmt.Printf("%s: $%d\n", p.Name, p.Price)
    }
}

Вывод (порядок Phone и Monitor может меняться):

Tablet: $300
Phone: $500
Monitor: $500
Laptop: $1000

Пример, когда стабильность важна:

package main

import (
    "fmt"
    "sort"
)

type Employee struct {
    Name       string
    Department string
    Salary     int
}

func main() {
    employees := []Employee{
        {"Alice", "Engineering", 80000},
        {"Bob", "Marketing", 70000},
        {"Charlie", "Engineering", 80000},
        {"Diana", "Marketing", 70000},
        {"Eve", "Engineering", 80000},
    }

    // Сначала сортируем по отделу (стабильно)
    sort.SliceStable(employees, func(i, j int) bool {
        return employees[i].Department < employees[j].Department
    })

    fmt.Println("После сортировки по отделу:")
    for _, e := range employees {
        fmt.Printf("%s (%s): $%d\n", e.Name, e.Department, e.Salary)
    }

    // Затем сортируем по зарплате (стабильно)
    // Порядок внутри одинаковых зарплат сохранится
    sort.SliceStable(employees, func(i, j int) bool {
        return employees[i].Salary < employees[j].Salary
    })

    fmt.Println("\nПосле сортировки по зарплате (стабильно):")
    for _, e := range employees {
        fmt.Printf("%s (%s): $%d\n", e.Name, e.Department, e.Salary)
    }
}

Вывод:

После сортировки по отделу:
Alice (Engineering): $80000
Charlie (Engineering): $80000
Eve (Engineering): $80000
Bob (Marketing): $70000
Diana (Marketing): $70000

После сортировки по зарплате (стабильно):
Bob (Marketing): $70000
Diana (Marketing): $70000
Alice (Engineering): $80000
Charlie (Engineering): $80000
Eve (Engineering): $80000

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

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

#GoDeep

🛠 go fix для бенчмарков

Классический стиль бенчмарков в Go завязан на b.N, и из-за этого часто появляются b.ResetTimer и другая ручная обвязка.

Инструменты из экосистемы Go умеют автоматически применять замену, чтобы код был проще и меньше ошибался. Один go fix и всё красиво.

Пример:

// До
func Benchmark(b *testing.B) {
    s := make([]int, 1000)
    for i := range s {
        s[i] = i
    }
    b.ResetTimer()

    for range b.N {
        Calc(s)
    }
}

// После
func Benchmark(b *testing.B) {
    s := make([]int, 1000)
    for i := range s {
        s[i] = i
    }

    for b.Loop() {
        Calc(s)
    }
}

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

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

#GoToProduction

💸 Код подешевел, а софт нет

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

Автор статьи предлагает смотреть на происходящее как на взрыв персонального софта, который живет ровно столько, сколько живет задача.

Скрипт под конкретный DOM сайта, одноразовый парсер банкинга, утилита для своей рутины в проекте, все это стало дешево за счет LLM и CLI first подхода. И это нормально, потому что одноразовость там фича, а не баг. Инструмент сделал свое дело и может спокойно умереть.

Но как только нужен продукт, а не разовая вещь, вступают в игру знакомые расходы, поддержка, изменения окружения, UX, данные, надежность.​
И LLM тут не спасают, они не проектируют архитектуру и не несут ответственность за системные решения, этим по прежнему занимаются инженеры.

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

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

#GoLive

✏️ Учим Go через практические задачи

Go Quests — это коллекция практических заданий для изучения Go. Репозиторий построен как серия квестов: вы решаете задачу, запускаете тесты и сразу видите, что работает, а что нет.

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

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

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

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

#GoLive

🔼 Требования к Go-разработчикам растут быстрее, чем обновляются резюме. То, что вчера считалось сильным навыком, завтра становится необходимым опытом.

🗓 15 января в 20:00 МСК пройдет встреча с двумя экспертами, которые формируют требования к рынку: рекрутером Ксенией Маловой, знающей, почему 90% кандидатов отсеиваются ещё до техсобеса, и архитектором Александром Хохловым, который понимает, какие инженерные компетенции станут критичными для новых проектов.

❗️ Разберём тренды, требования и реальные ожидания компаний, поговорим о том, какие пробелы чаще всего мешают росту и как сформировать долгосрочную траекторию развития в Go-разработке.

▶️ Встречаемся в преддверие старта курса «Golang Developer. Professional», регистрация открыта: https://clc.to/cE064g

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

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

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

#GoGiggle

🗑 Утечка тела ответа

Когда вы делаете HTTP-запрос в Go, клиент открывает соединение и выделяет буфер для тела ответа. Если не закрыть resp.Body, эти ресурсы остаются занятыми. Соединение висит в пуле, буфер держится в памяти.

Один забытый Close() — не проблема. Сто запросов в секунду без закрытия — уже катастрофа. Транспорт исчерпывает лимиты, новые соединения не открываются, запросы начинают таймаутиться.

Типичная ошибка:

resp, err := httpClient.Do(req)
if err != nil { 
    return err 
}
// читаем тело, возвращаем данные
// resp.Body.Close() отсутствует

Закрывайте resp.Body всегда. Даже если получили ошибку HTTP. Даже если статус не 200. Даже если не читаете тело ответа.

resp, err := httpClient.Do(req)
if err != nil { 
    return err 
}
defer resp.Body.Close()

// теперь читаете body или игнорируете

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

Добавьте линтер, который ловит незакрытые resp.Body. Например, bodyclose из golangci-lint. Он найдёт проблемные места автоматически.

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

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

#GoDeep