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

👨‍💻 Вызов Go-функции из JIT-кода

Go не создан для JIT-компиляции. Сборщик мусора требует строгой формы стека, и если JIT-код нарушает эти ожидания, программа падает с fatal error: unexpected signal during runtime execution. Разработчик решил эту проблему и опубликовал библиотеку gojit.

Почему это сложно

В Go два ABI. ABI0 передаёт аргументы через стек, ABIInternal через регистры. Внутри рантайма Go использует ABIInternal, снаружи видит ABI0. JIT-код об этом ничего не знает. Добавьте сюда сборщик мусора, который в любой момент может проверить стек, и прямой вызов Go-функций из JIT превращается в лотерею.

Как это решает gojit

Трюк в том, чтобы вызывать Go-функцию не напрямую из JIT-кода, а через метку внутри Go Assembly. Рантайм Go считает такой вызов легитимным и не падает при сборке мусора или росте стека.

В ассемблерный трамплин добавляется метка gocall:

TEXT ·callJIT(SB), 0, $8-8
    NO_LOCAL_POINTERS
    MOVQ code+0(FP), AX
    JMP AX
gocall:
    CALL CX
    JMP (SP)

Отдельная asm-функция возвращает точный адрес ABI0-реализации, а не адрес ABIInternal-обёртки, которую Go подставляет по умолчанию. Зная этот адрес, JIT-код кладёт указатель на Go-функцию в RCX, прыгает в gocall, функция выполняется, стек возвращается в порядок.

В библиотеке всё это спрятано за методом CallFunc(f func).

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

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

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

#GoDeep

⚙️ sync.Pool это не кэш

sync.Pool это один из самых неправильно понимаемых типов в стандартной библиотеке. Выглядит как пул объектов, им и является, но с одной гарантией, которая удивляет: GC может выселить всё содержимое пула в любой момент, без предупреждения.

Для чего он реально нужен

Один конкретный сценарий: снизить давление аллокаций для короткоживущих переиспользуемых объектов: bytes.Buffer, структуры протокольных сообщений, временные срезы.

var bufPool = sync.Pool{
    New: func() any {
        return new(bytes.Buffer)
    },
}

func processRequest(data []byte) []byte {
    buf := bufPool.Get().(*bytes.Buffer)
    buf.Reset() // обязательно: сбрасываем перед использованием
    defer bufPool.Put(buf)

    buf.Write(data)
    return buf.Bytes()
}

Две ошибки, которые случаются почти всегда

Забыть Reset(). Пул переиспользует объект, но не его содержимое. Всё, что записал предыдущий пользователь, никуда не делось. Всегда сбрасывайте состояние перед работой с полученным объектом.

Использовать объект после Put. Как только вызвали Put — объект принадлежит пулу. Обращение к buf.Bytes() после возврата — это гонка данных, которая просто ещё не выстрелила.

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

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

#GoDeep

❓ Что выведет код

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

💡 Подсказка: вспомните, как работает cmp.Or под капотом. Это не || из си-подобных языков

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

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

#ReadySetGo

Надоели шаблонные решения на ИТ-соревнованиях? На МТС True Tech Hack 2026 ценят нестандартные подходы.

Инженер данных, разработчик или системный аналитик — это про тебя? Тогда подключайся: победители разделят 1 500 000 рублей за разработку демоверсии ИИ-продукта.

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

Регистрация до 9 апреля здесь

💻 Свой Git-сервер, который запускается на Raspberry Pi

Gogs — self-hosted Git-сервис, написанный на Go. Это веб-интерфейс для работы с репозиториями, который разворачивается у вас на сервере.

По функциям похож на GitHub: репозитории, пул-реквесты, задачи, вики, вебхуки, деплой-ключи, организации, защищённые ветки.

Из необычного: поддержка Jupyter Notebook и PDF прямо в браузере, миграция репозиториев с других хостингов, Git LFS, аутентификация через LDAP, SMTP, GitHub и reverse proxy с поддержкой 2FA.

Требования к железу минимальные: хватит Raspberry Pi или VPS за $5. Для командной работы рекомендуется 2 ядра и 512 МБ ОЗУ. ОЗУ при росте команды почти не растёт, только процессор.

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

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

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

#GoToProduction

Почитали тут свежий отчёт по рынку ИИ-ускорителей в РФ: оказывается, 54% компаний тормозят внедрение ИИ исключительно из-за конских цен на инфраструктуру.

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

По сути, сейчас мало уметь собирать RAG. Нужно считать токены, настраивать time-travel дебаг в LangGraph и уметь роутить запросы на лету. Всё это мы учли в обновлённом курсе по разработке AI-агентов, где акцент сделан именно на AgentOps и жёсткий контроль ресурсов.

Также в программе:

— оценка качества, трейсинг и защита от деградации пайплайнов;
— мультиагентные паттерны и интеграция по протоколу MCP;
— локальный деплой Open Source под 152-ФЗ (когда данные нельзя выносить наружу).

Кажется, это единственный адекватный roadmap по переходу от блокнотов к enterprise-решениям.

Прямо сейчас можно урвать курс с увесистой скидкой (49 000 ₽ 62 990 ₽ за базовый тариф и 99 000 ₽ 124 990 ₽ за продвинутый трек), но стоит поторопиться — на потоке осталось всего 5 мест.

👉 Зафиксировать цену и начать собирать агентов, за которых не стыдно в проде

📎 Когда каналов недостаточно

Когда нужно скоординировать горутины, первый инстинкт — взять канал. Чаще всего это правильно. Но есть один конкретный сценарий, где sync.Cond не просто уместен, а является единственным чистым решением.

Проблема: оповестить произвольное число горутин

Допустим, у вас пул воркеров, которые ждут задачи в очереди. Воркеров может быть 3, может быть 50 — вы не знаете заранее.

Как оповестить их всех, когда появилась новая задача?

С каналом это неловко: нужно либо N отдельных каналов, либо закрыть канал, но это одноразово, либо делать fan-out горутину. Всё это хрупко, когда число потребителей меняется динамически.

sync.Cond решает это в одну строку: cond.Broadcast().

Пример кода:

type Queue struct {
    mu    sync.Mutex
    cond  *sync.Cond
    items []Job
}

func (q *Queue) Push(j Job) {
    q.mu.Lock()
    q.items = append(q.items, j)
    q.cond.Broadcast() // будим всех ожидающих
    q.mu.Unlock()
}

func (q *Queue) Pop() Job {
    q.mu.Lock()
    defer q.mu.Unlock()
    for len(q.items) == 0 {
        q.cond.Wait() // атомарно отпускает мьютекс и засыпает
    }
    j := q.items[0]
    q.items = q.items[1:]
    return j
}

cond.Wait() делает две вещи атомарно: отпускает мьютекс и засыпает. Когда горутина просыпается мьютекс снова захватывается автоматически. Без этой атомарности между отпустил лок и заснул было бы гоночное окно.

Broadcast или Signal: Broadcast() будит всех ожидающих, а Signal() ровно одного. Используйте Broadcast, когда изменение состояния важно многим; Signal — когда продвинуться может только один.

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

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

#GoDeep

Хочешь узнать про тренды инженерной культуры и разработки в российских ИТ-компаниях? Тогда присоединяйся к ИТ-вечеру в стиле «Русское техно» от МТС Web Services. 🙌

Двери особняка в парке Сокольники в Москве распахнутся 26 марта, чтобы собрать вместе бэкенд- и ML-разработчиков, которые строят современные ИТ-решения.

Участников ждут актуальные практики, мастер-классы, общение, игры и атмосфера вечеринки.

Ты узнаешь:

- какие инженерные культуры существуют у сильных ИТ-игроков на российском рынке, и как на них повлияло развитие ИИ;
- как компании внедряют ИИ в процесс разработки;
- как построить архитектуру для ИИ-агентов.

Попробуешь на практике:

- создать игру с помощью вайб-кодинга с MWS DevTools Agent;
- создать ИИ-агента.

Когда: 26 марта в 18:00
Москва + онлайн

👉 Количество участников ограничено, успей зарегистрироваться по ссылке.

🔍 Критическая дыра в gRPC-Go: обход авторизации

gRPC-Go сервер слишком мягко обрабатывал маршрутизацию: он принимал запросы, где в заголовке :path отсутствовал обязательный ведущий слэш — например, Service/Method вместо /Service/Method.

Сервер успешно направлял такие запросы нужному обработчику, но перехватчики авторизации, включая официальный пакет grpc/authz, проверяли сырую, неканоническую строку пути.

Кто под угрозой

Уязвимость затрагивает серверы, у которых одновременно:

• используются перехватчики авторизации по пути (grpc/authz, кастомные через info.FullMethod)

• политика содержит явные правила запрета + резервное «разрешить»

Атакующему достаточно отправить сырые HTTP/2-фреймы с кривым заголовком :path — без привилегий и взаимодействия с пользователем.

Лучшее решение — обновиться до v1.79.3, где запросы без ведущего слэша сразу отклоняются с ошибкой codes.Unimplemented.

➡️ Источник

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

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

#GoToProduction

⚡️ Wire стал быстрее в 70 раз. Как это стало возможным

Если вы работаете с Go и используете Wire для генерации зависимостей, то наверняка знаете это чувство: запускаете wire gen, ждёте секунду-две, и так сотни раз за день. Мелочь? Нет. Это накапливается.

Go-Разработчик решил разобраться с этим и результат получился серьёзный.

В чём была проблема

Предыдущие попытки ускорить Wire давали 8-10x на отдельных сценариях, но не решали главное. На каждом запуске Wire заново делал одно и то же: полный обход графа зависимостей через go/packages и полную проверку типов через go/types.

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

На крупных кодовых базах Wire легко уходил в 1-3 секунды на каждый прогон. Умножьте это на тысячи запусков за время разработки.

Что изменилось

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

Результат по сценариям для проекта с 42 локальными, 243 стандартными и 342 внешними пакетами в графике к посту.

Холодный старт стал медленнее — это цена построения кэша. Но в реальной разработке холодный старт случается один раз, а повторные запуски идут в 14-74 раза быстрее.

Все существующие тесты Wire проходят. Добавлены новые тесты под конкретные сценарии кэширования. При любом подозрительном состоянии кэша Wire откатывается к полному пересчёту. Автор использует это в своей работе уже несколько недель.

Как попробовать

Установить тестовую сборку можно одной командой:

go install github.com/goforj/wire/cmd/wire@cf52879

Чтобы понять размер своей кодовой базы перед тестом:

go list -deps -json ./... | \
  jq -r '
    select(.ImportPath != null) |
    if .Standard then "stdlib"
    elif (.Module != null and .Module.Main == true) then "local"
    else "external"
    end
  ' | sort | uniq -c

Если вы уже используете Wire и у вас достаточно большой проект, именно ваши тесты сейчас нужны. Разработчик просит активно делиться результатами.

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

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

#GoLive