📎 Новый экспериментальный сборщик мусора в Go

Go 1.25 представил новую экспериментальную версию сборщика мусора под названием Green Tea, которая уже доступна для тестирования и активно используется внутри Google.

Основная цель Green Tea — снизить нагрузку на CPU, связанную с работой сборщика мусора.

Green Tea предлагает принципиально новый подход к алгоритму mark-sweep, который лежит в основе сборки мусора в Go. Вместо того чтобы сканировать объекты по отдельности, Green Tea работает с целыми страницами памяти.

Однако, как и любой экспериментальный компонент, Green Tea не всегда даёт прирост производительности.

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

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

➡️ Подробнее об этом в блоге Go разработчиков

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

#GoDeep

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

#GoGiggle

🎃 Хэллоуин в айти

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

💬 Если сегодня кто-то оделся необычно, расскажите в комментах 👇

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

#GoTalk

Как вырасти в тимлида за 4 года? Слушаем мнение Егора Гартмана, технического руководителя команды в вертикали Недвижимость в Авито✨

Он прошёл этот путь самостоятельно и теперь стал новым гостем «AviTalk» — это шоу о сотрудниках Авито, их интересах, целях в работе и вне её. Вместе с ведущим Виктором Раевым они обсудили:

☑ как выглядят команды внутри Авито и как различается их функционал?
☑ как меняется жизнь, когда ты теперь тимлид?
☑ как проводить собеседования и качать софт-скиллы?
☑ и как расслабляться, покоряя снежные вершины?

📺Смотрим по ссылке!

🧑‍💻 Неправильный Ctrl-C Ctrl-V

В Go есть правило: типы из пакета sync нельзя копировать.

Почему нельзя копировать sync-типы

sync.Mutex содержит внутренние поля и при копировании значения эти поля дублируются, но копии не синхронизированы.

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

Практический пример:

type Counter struct {
    mu       sync.Mutex
    counters map[string]int
}

func (c Counter) Increment(name string) { 
    c.mu.Lock()
    defer c.mu.Unlock()
    c.counters[name]++
}

Здесь каждый вызов Increment создаёт копию всей структуры Counter, включая sync.Mutex. Каждая горутина получает свой мьютекс, что полностью ломает синхронизацию.

Решением этой проблемы может стать указатель на структуру или на мьютекс:

type Counter struct {
    mu       *sync.Mutex
    counters map[string]int
}

func NewCounter() Counter {
    return Counter{
        mu: &sync.Mutex{},
        counters: map[string]int{},
    }
}

Даже если Counter скопируется, обе копии будут использовать один мьютекс через указатель.

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

#GoToProduction

🤩 Финальный рывок

Финишировали тяжелую 6-дневку, теперь можно переключиться на отдых. Делайте то, что нравится, отвлекайтесь от рабочих мыслей.

💬 А как у вас прошла эта неделя? Что планируете на выходные? Делитесь своими планами 👇

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

#GoTalk

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

Вот и закончились 6 рабочих дней. Вспоминаем как это было.

— Cursor 2.0

Cursor представил ускоренную модель Composer и обновленный интерфейс для параллельной работы с агентами, улучшая код-ревью и автоматическое тестирование.

— Отчёт по языкам от GitHub

Вышел ежегодный Octoverse от GitHub, в котором отмечается рекордный рост числа разработчиков, активность в проектах с AI и смена лидерства по языкам программирования.

— Реверс-прокси с балансировкой

— LLM сражаются в покерном турнире

— Разработчики рассказали как работает новый GC

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

#GoLive

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

#GoGiggle

💻 Когда i нормально, а d — преступление

Go поощряет краткость но не в ущерб смыслу. Правило простое: коротко для локального и широко для интерфейса и домена

Список общепринятых сокращений переменных:

• i, j, k — циклы
• err — ошибки
• ctx — контекст
• r, w — Reader, Writer
• u, d, s — Receiver'ы методов. Первая буква типа.
• db — Database
• cfg — Config
• buf — буфер
• ok — флаг успеха
• n — number, количество
• v — value. Только с range
• _ — Throwaway. Игнорируем результат.
• conn — Connection

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

#GoToProduction

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

Senior Golang Developer — от 350 000 ₽. Удаленно по Москве.

Архитектор — от 500 000 ₽

Старший разработчик Go — от 300 000 ₽. Гибрид или офис в Москве

Golang Developer — до 6 000$ на удалёнку по Португалии

Golang-разработчик — 250 000 ₽ и офис в Москве

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

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

#GoWork

📎 Кастомные ошибки в Go

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

Кастомный тип ошибки — это структура, которая содержит не только сообщение, но и дополнительные данные. Это позволяет обработчику ошибки принять осознанное решение: может, это ошибка валидации и стоит показать пользователю сообщение о неправильном вводе.

Как это выглядит на практике:

// Определяем свой тип ошибки
type InvalidInputError struct {
    FieldName string
    Value     string
}

// Реализуем интерфейс Error()
func (e *InvalidInputError) Error() string {
    return fmt.Sprintf("invalid input for field '%s': '%s'", e.FieldName, e.Value)
}

// Используем его в функции
func processInput(input string) error {
    if len(input) == 0 {
        return &InvalidInputError{FieldName: "input", Value: input}
    }
    return nil
}

// А вот и обработка
func main() {
    err := processInput("")
    if err != nil {
        if invalidErr, ok := err.(*InvalidInputError); ok {
            fmt.Printf("Validation error: %s (Field: %s)\n", invalidErr.Error(), invalidErr.FieldName)
        } else {
            fmt.Printf("Unexpected error: %s\n", err)
        }
    }
}

Мы поймали ошибку через type assertion и получили доступ к полям структуры. Это даёт намного больше гибкости, чем просто if err != nil.

В современном Go для распаковки обёрнутых ошибок есть errors.As() — это удобнее, чем type assertion, особенно если ошибку кто-то обернул через fmt.Errorf("%w", err).

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

#GoDeep

⚙️ Docker команды, которые должен знать разработчик

Сколько раз вы открывали терминал и забывали простую Docker команду? Гугл в помощь, потом опять ищете то же самое через неделю. Рассказываем про команды, которые нужны в реальной работе.

Вам нужно видеть, какие контейнеры работают прямо сейчас:

docker ps

Это покажет только живые контейнеры. Но если контейнер упал или его остановили, он исчезнет из списка.

Чтобы увидеть всё, включая мёртвые:

docker ps -a

Самая частая команда в разработке:

docker run -d -p 8080:80 nginx

Разбираем:
-d — запустить в фоне, чтобы терминал не занимался.
-p 8080:80 — проксировать локальный порт 8080 на порт 80 внутри контейнера.
nginx — образ, который запускаем.

Результат: контейнер крутится в фоне, вы можете открыть http://localhost:8080 и увидите nginx.

Контейнер поднялся, поэкспериментировали, теперь нужно его убить:

docker stop имя-или-id

Контейнер остановится, но останется на диске.

Если нужно удалить совсем:

docker rm имя-или-id

Или в один ход — остановить и удалить:

docker rm -f имя-или-id

Флаг -f форсирует удаление даже если контейнер работает.

Посмотреть все образы у вас на машине:

docker images

Удалить образ, если он вам больше не нужен:

docker rmi название-образа

Если удалите образ, контейнеры которые на нём основаны, перестанут работать.

Контейнер падает или работает странно? Посмотрите логи:

docker logs имя-или-id

Это покажет всё что контейнер вывел в stdout.

Можно добавить флаг -f чтобы следить в реальном времени:

docker logs -f имя-или-id

Иногда нужно залезть внутрь контейнера и что-то проверить. Откройте интерактивный шелл:

docker exec -it имя-или-id bash

Флаг -it означает интерактивный терминал. Теперь вы внутри, можете запускать команды, смотреть файлы, отлаживать.

Ещё полезно посмотреть детали контейнера:

docker inspect имя-или-id

Будет JSON со всей информацией: какие переменные окружения, какие портами, версии образа, сетевая конфигурация.

Со временем контейнеры и образы накапливаются. Чистим:

docker system prune -a

Это удалит все остановленные контейнеры, все неиспользуемые образы, сети и volumes которые ни на что не ссылаются.

Контейнер падает, данные теряются — такое быть не должно. Для этого есть тома:

docker volume create my_volume

Теперь у вас есть том. Запускаете контейнер и монтируете том внутрь:

docker run -d -v my_volume:/data nginx

Флаг -v монтирует том my_volume в папку /data внутри контейнера. Когда контейнер упадёт, данные в томе остаются. Запустите контейнер снова — данные на месте.

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

docker network create my_network

Теперь запускаете контейнеры в этой сети:

docker run -d --network my_network --name api nginx
docker run -d --network my_network --name db postgres

Контейнеры внутри сети видят друг друга по имени. Это удобнее чем помнить IP адреса.

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

#GoToProduction

🛠 Как найти и починить утечки, которые валят API

API падает каждый день? Память растёт, горутины множатся, потом крах. Это не магия — это утечки ресурсов. Вот как их найти и убить.

Шаг 1: Собрать доказательства перед тем как гадать

Не начинайте с предположений. Сначала соберите логи. Ищите паттерны: растут ли таймауты, появляются ошибки «context canceled», скачет ли error rate?

Heap и goroutine профили. Это главное. Добавьте pprof endpoint, если его нет:

import _ "net/http/pprof"

go func() { 
    log.Println(http.ListenAndServe(":6060", nil)) 
}()

На следующем инциденте вытащите профили:

curl localhost:6060/debug/pprof/heap > heap.pb
curl localhost:6060/debug/pprof/goroutine?debug=2 > goroutines.txt

Проверьте лимиты: /proc/<pid>/limits, количество открытых файловых дескрипторов, состояние сокетов.

Шаг 2: Прочитать профили и понять, что протекает

Откройте goroutine профиль текстом — там все ответы:

go tool pprof -http=:8080 heap.pb

Что нужно найти:

• Горутины в CLOSE_WAIT. Это сокеты, которые никто не закрыл нормально.

• Горутины, зависшие на channel send/receive. Если тысячи горутин ждут отправить или получить из канала — канал где-то забился или заблокирован.

• Горутины в syscall. Много горутин ждут на сетевых операциях — это может быть утечка соединений или зависание на стороне сервера.

Шаг 3: Найти корни утечек в коде

Три главных виновника:

• Горутины без контекста. Запустили горутину для async операции, но не гарантировали её завершение:

// Плохо: горутина может зависнуть
go func() {
    resp, _ := http.Get(url)
    // ...
}()

// Хорошо: контекст отменяет работу
go func(ctx context.Context) {
    req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
    resp, _ := httpClient.Do(req)
}(r.Context())

• HTTP клиенты без переиспользования. Создаёте нового клиента на каждый запрос:

// Плохо: новый Transport на каждый вызов
func handleRequest(w http.ResponseWriter, r *http.Request) {
    client := &http.Client{}
    resp, _ := client.Get("https://api.example.com/data")
}

// Хорошо: переиспользуем один клиент
var httpClient = &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        200,
        MaxIdleConnsPerHost: 100,
        IdleConnTimeout:     90 * time.Second,
    },
}

• Неограниченные очереди. На пике нагрузки канал растёт без предела:

// Плохо: неограниченный канал
jobs := make(chan Job)

// Хорошо: ограничиваем размер
jobs := make(chan Job, 1000)

select {
case jobs <- job:
    // принято
default:
    http.Error(w, "перегружены", http.StatusServiceUnavailable)
}

Чтобы не падать в проде можно попробовать имитировать нагрузку на дев стенде:

# Генерируем нагрузку
ab -n 100000 -c 100 http://localhost:8080/endpoint

# В другом терминале снимаем профиль каждую минуту
for i in {1..60}; do
  curl localhost:6060/debug/pprof/goroutine?debug=1 > goroutine_$i.txt
  sleep 60
done

Растёт ли количество горутин? Если да — утечка. Если нет — ложная тревога.

Не полагайтесь только на профили. Мониторьте в реальном времени:

// Метрика: количество горутин
runtime.NumGoroutine()

// Метрика: память
var m runtime.MemStats
runtime.ReadMemStats(&m)
m.Alloc // текущее использование

// Метрика: открытые файловые дескрипторы (Linux)
files, _ := ioutil.ReadDir("/proc/self/fd")
len(files) // количество открытых fd

Выставляйте эти метрики в Prometheus или что у вас есть. Алерты на рост горутин выше нормы — это первый звоночек.

Не решайте задачу вслепую. Профилируйте, смотрите данные, ищите паттерны. Утечки это не магия — это просто ресурсы, которые вы забыли закрыть.

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

#GoToProduction

✏️ FizzBuzz — классика собеседований

Задача проста на вид, но открывает много вопросов на интервью. Вот почему её так любят спрашивать.

Дано число n. Нужно вернуть массив строк, где для каждого числа от 1 до n:

• если кратно и 3 и 5 — «FizzBuzz»
• если кратно 3 — «Fizz»
• если кратно 5 — «Buzz»
• иначе — само число как строку

Решение:

func fizzBuzz(n int) []string {
    res := make([]string, n)
    for i := 1; i <= n; i++ {
        res[i-1] = strconv.Itoa(i)
        if i % 3 == 0 { res[i-1] = "Fizz" }
        if i % 5 == 0 { res[i-1] = "Buzz" }
        if i % 15 == 0 { res[i-1] = "FizzBuzz" }
    }
    return res
}

Число 15 — это наименьшее общее кратное чисел 3 и 5. Когда число одновременно делится на 3 и на 5, оно всегда делится на 15.

На собеседовании сначала напишите просто, потом обсудите улучшения. FizzBuzz — не про трюки синтаксиса, а про чистоту мышления и умение общаться с интервьюером.

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

#ReadySetGo

🧑‍💻 Среда или понедельник

Как у вас началась рабочая трёхдневка? У админа сбились абсолютно все настройки по пониманию какой сейчас день недели. Тяжелее только новогодние праздники.

💬 Работаете или взяли хитрый отпуск? Ждём вас в комментах 👇

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

#GoTalk