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

Middle GoLang Developer — удалёнка по США

Senior Golang Developer — офис в Москве

Golang developer — гибрид в МСК

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

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

#GoWork

🗓 В следующий вторник (28.04) в 19:00 встречаемся в онлайне.

Тема:

Как эффективно управлять контекстным окном LLM в мультиагентных системах и не сливать бюджет на токены

В кружке Кирилл Кухарев рассказал, какие именно подходы будем разбирать.

👉 Занять место на вебинаре

⚙️ slicessort: заменяем sort.Slice на slices.Sort

В Go есть анализатор slicessort из пакета golang.org/x/tools/go/analysis. Он находит в коде паттерны сортировки через sort.Slice с простой функцией сравнения и предлагает заменить их на slices.Sort.

Что он решает

Раньше, чтобы отсортировать срез базовых типов по возрастанию, писали так:

sort.Slice(s, func(i, j int) bool { return s[i] < s[j] })

Это работает, но многословно. Начиная с Go 1.21 есть slices.Sort, которая делает то же самое без лишнего кода:

slices.Sort(s)

Анализатор проверяет вызовы sort.Slice и ищет те, где функция-компаратор просто сравнивает элементы через <. Если срез содержит упорядоченный базовый тип (int, string, float64 и другие), анализатор помечает такой вызов и предлагает замену.

Запустить можно через go vet или любой линтер, поддерживающий analysis.Analyzer:

go vet -vettool=$(which slicessort) ./...

Или через golangci-lint, если анализатор подключён в конфиге.

slicessort не делает ничего сложного. Он просто убирает бойлерплейт там, где стандартная библиотека уже давно предлагает лучше. Если проект на Go 1.21+, стоит добавить его в пайплайн.

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

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

#GoToProduction

🛠 make как точка входа в Go-проект

Когда работаете над Go-проектом в команде, быстро появляется проблема: каждый запускает сборку и тесты по-своему. Один пишет go build -o app, другой забыл флаги линтера, третий вообще не знает, какую команду использовать. Makefile решает это раз и навсегда.

Что такое Makefile и зачем он нужен

Makefile это файл с набором именованных команд. Вы описываете, что делает каждая цель, а потом вызываете её одним словом. Больше не нужно помнить длинные команды или держать их в заметках.

Вот базовый пример для Go-проекта:

run:
  go run .

test:
  go test ./...

lint:
  golangci-lint run

build:
  go build -o app

Теперь вместо того, чтобы каждый раз вспоминать точный синтаксис:

make run
make test
make build

Как это работает

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

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

check: lint test

Или сделать build зависимым от test, чтобы не собирать проект с непрошедшими тестами:

build: test
  go build -o app

Makefile быстро обрастает полезными целями. Несколько примеров:

.PHONY: run test lint build clean

clean:
  rm -f app

tidy:
  go mod tidy

cover:
  go test ./... -coverprofile=coverage.out
  go tool cover -html=coverage.out

Директива .PHONY говорит make, что эти цели не являются именами файлов. Без неё, если в директории окажется файл с именем build, make решит, что цель уже выполнена и ничего не запустит.

Makefile это простой способ зафиксировать рабочие команды проекта в одном месте. Новый человек в команде запускает make build и всё работает так же, как у остальных. Не нужно читать README в поисках нужной команды и не нужно помнить флаги наизусть.

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

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

#GoDeep

🔄 Gitea 1.26.0

Вышел крупный релиз Gitea с новыми возможностями в Actions, улучшениями интерфейса и несколькими исправлениями безопасности.

В релизе закрыты три CVE.

CVE-2026-28737 — stored XSS в просмотрщике 3D-файлов через поле extensionsRequired формата glTF.
CVE-2026-22555 — API форка позволял утечь секреты организации из-за отсутствия проверки CanCreateOrgRepo. CVE-2026-27780 — обход защиты веток через молчаливое усечение в bufio.Scanner при обработке pre-receive хука.

Actions

Пожалуй, самое заметное в релизе. Теперь поддерживается синтаксис concurrency как в GitHub Actions — новые запуски могут отменять или ставить в очередь предыдущие в той же группе. Появилась визуализация зависимостей между джобами прямо в интерфейсе. Можно перезапускать только упавшие джобы, не перегоняя весь воркфлоу.

Воркфлоу из приватных репозиториев теперь доступны как reusable. Токены Actions получили настраиваемые права по принципу минимальных привилегий. Администраторы могут приостанавливать и отключать отдельные раннеры без их удаления.

Интерфейс и работа с репозиторием

Добавили скачивание архива для поддиректории. Прямо в редакторе релизов теперь генерируются release notes из merged PR и списка контрибьюторов. В браузере файлов появились кнопки «Перейти к файлу» и «Удалить директорию».

Редактор кода переехал с Monaco на CodeMirror. Сборка фронтенда мигрировала с webpack на Vite. Появился Terraform state registry, теперь можно хранить стейт прямо в Gitea с теми же правами доступа, что и у кода.

Что важно знать перед обновлением

Несколько изменений ломают обратную совместимость. Утилита environment-to-ini удалена, вместо неё появилась подкоманда gitea config edit-ini. GET-эндпоинт для получения токена регистрации раннера удалён. Swagger-аннотации исправлены и теперь точнее описывают реальное API — если вы генерируете клиенты из спецификации, их нужно пересобрать. PUBLIC_URL_DETECTION теперь по умолчанию auto.

➡️ Источник

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

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

#GoLive

⚡️ Нельзя присваивать sync.Mutex между переменными

sync.Mutex не просто структура с двумя полями. Это объект с состоянием, и если вы присвоите один мьютекс другому во время работы горутин, получите либо панику, либо гонку данных.

Что происходит при присвоении

Посмотрите на этот код:

var mu1 sync.Mutex
var mu2 sync.Mutex

// Горутина 1: захватывает mu1
go func() {
    mu1.Lock()
    defer mu1.Unlock()
    // работа...
}()

// Горутина 2: заменяет mu1 на mu2
go func() {
    mu1 = mu2 // замена мьютекса прямо во время использования
}()

Здесь два опасных сценария.

Сценарий 1: паника

Горутина 1 захватила mu1. Горутина 2 присвоила mu1 = mu2. Теперь mu1 — это чистый, незахваченный мьютекс. Когда горутина 1 дойдёт до Unlock(), она попытается разблокировать мьютекс, который никто не блокировал, и получит панику:

unlock of unlocked mutex

Присвоение переменных не создаёт отношения happens-before между горутинами, в отличие от запуска и завершения горутины. Поэтому порядок, в котором горутина 1 увидит изменение mu1, непредсказуем.

Сценарий 2: гонка данных

Если горутина 1 разблокирует mu1 в тот же момент, когда горутина 2 делает присвоение, обе одновременно записывают в поля state и sema внутри структуры sync.Mutex. Это классическая гонка данных. Итог — повреждение состояния одного или обоих мьютексов.

Как делать правильно

Не присваивайте мьютексы напрямую. Если нужно передать мьютекс в другое место, используйте указатель:

var mu sync.Mutex

// Передаём указатель, а не копию
go func(m *sync.Mutex) {
    m.Lock()
    defer m.Unlock()
    // работа...
}(&mu)

Это же правило распространяется на структуры, которые содержат sync.Mutex. Копировать их тоже нельзя. Только передавать по указателю:

type SafeCounter struct {
    mu    sync.Mutex
    count int
}

// Правильно
func increment(c *SafeCounter) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.count++
}

// Неправильно: мьютекс скопируется вместе со структурой
func incrementWrong(c SafeCounter) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.count++
}

Инструмент go vet умеет находить такие копирования и выдаёт предупреждение copylocks.

sync.Mutex нельзя копировать или присваивать после первого использования. Передавайте мьютексы и структуры с ними только по указателю.

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

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

#GoDeep

🤔 Сравнили слайс с nil

На первый взгляд slices.Equal(nil, []int{}) вернёт false. Но по какой причине?

Подумайте что сравнивает slices.Equal и сравните свой ответ с нашим.

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

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

#ReadySetGo

😎 Реализации очередей для Go

В стандартной библиотеке Go нет готовых очередей. Можно написать свою на слайсах, но тогда придётся самому думать о race conditions, блокировках и сбросе состояния. Пакет queue от adrianbrad закрывает эту задачу: четыре реализации с единым интерфейсом и встроенной потокобезопасностью.

Что внутри

Все структуры реализуют один интерфейс Queue[T comparable]. Методы одинаковые у всех: Get, Offer, Peek, Contains, Size, IsEmpty, Reset, Clear, Iterator.

Четыре реализации:

BlockingQueue — FIFO с блокирующими методами. Если очередь пуста, Get ждёт. Если заполнена, Offer ждёт. Внутри использует sync.Cond. Подходит для классических producer-consumer задач.

PriorityQueue — порядок элементов задаётся функцией-компаратором. Реализована через container/heap. Полезна, когда нужно обрабатывать задачи не по порядку прихода, а по приоритету.

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

LinkedQueue — связный список, O(1) на добавление и удаление. Хранит указатели на голову и хвост, поэтому не нужен обход списка.

Установка:

go get -u github.com/adrianbrad/queue

Пример BlockingQueue:

package main

import (
    "fmt"
    "github.com/adrianbrad/queue"
)

func main() {
    elems := []int{2, 3}
    bq := queue.NewBlocking(elems, queue.WithCapacity(3))

    _ = bq.Offer(1)

    elem, err := bq.Get()
    if err != nil {
        // handle err
    }
    fmt.Println(elem) // 2
}

Пример PriorityQueue:

pq := queue.NewPriority(
    []int{2, 3, 4},
    func(a, b int) bool { return a < b },
)

_ = pq.Offer(1)

elem, _ := pq.Get()
fmt.Println(elem) // 1 — минимальный элемент

Бенчмарки:

BenchmarkBlockingQueue/Get_Offer-8    27135865    47.00 ns/op
BenchmarkCircularQueue/Get_Offer-8    32379159    36.83 ns/op
BenchmarkLinkedQueue/Get_Offer-8      61257436    18.48 ns/op
BenchmarkPriorityQueue/Get_Offer-8    29347177    39.88 ns/op

LinkedQueue самый быстрый на Get/Offer. CircularQueue не делает аллокаций при операциях, что важно под нагрузкой.

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

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

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

#GoToProduction

🤔 Есть ощущение, что Go незаслуженно обделён контентом на русском

Докажите обратное — кого смотрите по Golang? YouTube, телеграм — скидывайте в комменты👇 Может есть авторы c хабра, которые вам по душе?

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

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

#GoTalk

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

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

#GoGiggle

🔥 Недельный дайджест

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

— Попросить ИИ улучшить резюме это не стратегия

— WiFi на ESP32 через TinyGo

— Gitea 1.26.0

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

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

#GoLive

👨‍💻 slices.Delete — чище, безопаснее, без утечек

Анализатор slicesdelete из пакета golang.org/x/tools/go/analysis/passes/modernize находит места в коде, где стоит slices.Delete применить вместо ручного append.

Что было раньше

Удаление элементов из среза выглядело так:

s = append(s[:i], s[j:]...)

Работает, но неочевидно. Нужно держать в голове, что именно здесь происходит, и при быстром чтении легко пропустить.

Что предлагает анализатор:

s = slices.Delete(s, i, j)

Тот же результат, но намерение читается сразу: удалить элементы с индекса i по j.

Важный нюанс

slices.Delete не просто сокращает длину среза. Она зануляет элементы между новой и старой длиной. Это защита от утечки памяти: старый append-вариант оставлял ссылки на объекты в «хвосте» среза, и сборщик мусора не мог их освободить. Именно поэтому анализатор отключён по умолчанию.

Когда включать

Если в коде нет намеренной зависимости от того, что элементы за len остаются в памяти включайте анализатор и применяйте замену. Для большинства случаев это просто улучшение читаемости и безопасности.

Включить анализатор можно через флаг при запуске:

go vet -modernize.slicesdelete ./...

или в конфигурации golangci-lint, если используете его в проекте.

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

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

#GoToProduction

👨‍💻 GopherCon 2026

С 3 по 6 августа пройдёт GopherCon 2026. В этот раз конференция переезжает в Сиэтл.

Комитет сейчас разбирает больше 150 докладов, программа появится 4 мая. Будем следить.

➡️ Источник

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

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

#GoLive

🛠 Инструментарий для работы с WebAssembly

Если вы работаете с WebAssembly и пишете на Go, раньше приходилось тянуть зависимости на C++ (wabt) или Rust (wasm-tools). Теперь есть нативная альтернатива.

Что это

watgo это либа для работы с WebAssembly на чистом Go, без внешних зависимостей. Умеет парсить текстовый формат WebAssembly, валидировать его и компилировать в бинарный WASM и декодировать WASM обратно в структурное представление.

В основе лежит пакет wasmir — семантическое представление WASM-модуля, с которым удобно работать программно.

Установка:

go install github.com/eliben/watgo/cmd/watgo@latest

Скомпилировать WAT в WASM можно одной командой:

watgo parse stack.wat -o stack.wasm

Пример работы через API

Парсим WAT-модуль и анализируем инструкции:

m, err := watgo.ParseWAT([]byte(wasmText))
if err != nil {
    panic(err)
}

for _, fn := range m.Funcs {
    for _, instr := range fn.Body {
        switch instr.Kind {
        case wasmir.InstrLocalGet:
            // обработка
        case wasmir.InstrI32Add:
            // обработка
        }
    }
}

Функции модуля хранятся в m.Funcs, каждая содержит плоский список инструкций fn.Body. Имена и типы при парсинге резолвятся в числовые индексы — так же, как это устроено в бинарном формате WASM.

Тестирование

Проект прошёл официальный тест-сьют WebAssembly — почти 200 тысяч строк WAT-файлов с описанием ожидаемого поведения. Бинарный вывод watgo прогоняется через Node.js и сверяется со спецификацией.

➡️ Источник | Репозиторий

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

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

#GoToProduction

🤖 Конец накрутки опыта

HeadHunter официально анонсировал 4-шаговый план по борьбе с фродом в резюме. Первые шаги уже сделаны в 2025-м — тестовые баны и привязка Госуслуг.

В 2026-м добавляется сверка с электронной трудовой книжкой. Несовпадение дат и аккаунт летит в бан без возможности восстановления.

➡️ Что делать, если опыт «серый», а часть опыта накрученная

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

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

📊 heap-профилирование без единой строки кода

Coroot выпустили zero-config heap-профилирование для Go. Агент читает профили прямо из памяти работающего процесса через /proc/<pid>/mem, не трогая сам процесс и не требуя от него ничего.

Раньше, чтобы получить heap-профиль Go-сервиса, нужно было подключить net/http/pprof, поднять эндпоинт, настроить скрейпинг. Если сервис чужой или деплой нежелателен, то вы просто не получали данных. Coroot решил эту проблему на уровне ноды.

Механика такая: Go-рантайм уже собирает heap-профили внутри себя через runtime.MemProfile(). Данные живут в глобальной переменной runtime.mbuckets. Coroot находит адрес этой переменной в символьной таблице бинаря, читает связный список бакетов и конвертирует всё в pprof-формат.

Два нетривиальных момента, которые пришлось решить:

Stripped-бинари. Бинарь собран с -ldflags="-s" и символьная таблица отсутствует и найти mbuckets невозможно. Такие процессы пропускаются.

Линкер отключает профилирование. Если в бинаре нет импорта runtime/pprof или net/http/pprof, линкер выставляет флаг disableMemoryProfiling и рантайм устанавливает MemProfileRate = 0. Profiling не работает вообще. Coroot умеет это обнаружить и записать дефолтное значение обратно через тот же /proc/<pid>/mem:

--go-heap-profiler=disabled  # выключено
--go-heap-profiler=enabled   # по умолчанию, только пассивное чтение
--go-heap-profiler=force     # записывает MemProfileRate если он равен нулю

Как это выглядит в деле

Команда показала два демо-сценария на сервисе product-catalog.

Первый: включили GC-давление. Каждый запрос прогонял маршаллинг/анмаршаллинг данных десятки раз и строил ненужные структуры суммарно на ~2 МБ. Латентность api-gateway выросла с 0.16s до 3.76s. CPU-профиль показал gcBgMarkWorker — GC грузит CPU, но не понятно откуда. Heap-профиль сразу указал на main.inefficientEnrichProducts с JSON-энкодерами и аллокациями в цикле.

Второй: включили утечку памяти. Каждый запрос добавлял данные в глобальный срез без удаления. Память росла быстро. RCA-движок Coroot сравнил heap-профиль во время инцидента с профилем до него и выдал дифф: main.appendToProductCache отвечает за 99.6% новых аллокаций. Не «что-то растёт», а конкретная функция.

Что добавилось в метрики

Поскольку агент уже считает дельты аллокаций по бакетам, два новых счётчика появились бесплатно:

container_go_alloc_bytes_total    # байты аллоцированные за период
container_go_alloc_objects_total  # объекты аллоцированные за период

Heap-профилирование теперь работает для любого Go-процесса на ноде без изменений в коде, без pprof-эндпоинтов, без рестарта. Особенно полезно SRE-командам, которые обслуживают сервисы, написанные другими.

➡️ Источник

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

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

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

#GoToProduction