Доклады конференции Golang Conf 2026

Раcскажем об AsyncAPI как о спецификации для описания асинхронных взаимодействий в микросервисной архитектуре. Поделимся опытом использования инструментов для кодогенерации по спецификации AsyncAPI для NATS.
Рассмотрим подводные камни specification-first в случае AsyncAPI для Go, покажем как бесшовно подружить AsyncAPI с OpenAPI и CloudEvents.
Продемонстрируем нестандартные подходы к применению кодогенерации по AsyncAPI на примере transactional outbox.

Я расскажу о новом garbage collector - "зеленый чай", какие проблемы были у mark-sweep алгоритма, как "зеленый чай" их решил, как разработчикам языка удалось использовать современные инструкции процессоров AVX-512. Посмотрим на примере конкретного приложения насколько GC стал работать лучше.

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

В рамках доклада я расскажу про работу с учетными записями в условиях использования большого количества различных IAM, предоставляющих разные API и схемы данных.
Обсудим классические подходы работы с пользователями на Golang, способы стандартизации API и приведения данных из разных баз пользователей к единой схеме, а также сохранения совместимости с целевой Linux системой и ее утилитами.

Мы все используем AI-агентов (в IDE или чатах) для написания кода на Go. Но часто агент начинает "галлюцинировать", забывать библиотеки или игнорировать стиль проекта, потому что его контекст переполнен или зашумлен.
Обычное решение — скидывать куски кода вручную.
Правильное решение — использовать систему Rules (файлы правил), из которых агент сам выбирает нужное.

В докладе я расскажу, как спроектировать и "отрефакторить" сами .md файлы правил, чтобы агент работал как опытный член команды, а не джуниор.

Недавно в Go появилась поддержка WebAssembly (WASM) и WebAssembly System Interface (WASI). Это открывает новые возможности для Go-разработчиков: безопасную изоляцию кода, динамическую загрузку модулей в рантайме, контроль API и создание расширяемых систем без перекомпиляции основного приложения.
Мы разрабатываем Deckhouse Kubernetes Platform и используем для расширения функциональности платформы модульную архитектуру. На примерах из практики я покажу, как можно реализовать модули бизнес-логики на Go, используя WebAssembly. Такой подход позволяет добавлять новые возможности для пользователей без изменения ядра платформы, обходить ограничения традиционной компиляции и динамических библиотек.
Из доклада вы узнаете о различиях между превью-версиями WASI, текущих ограничениях Go при работе с WebAssembly, разнице между компиляторами WASM и вариантах WASM runtime. А примеры покажут, как создавать безопасные и изолированные модули, и помогут оценить, будет ли WebAssembly полезен для ваших проектов. Будет интересно как начинающим, так и опытным разработчикам, исследующим возможности WASM в контексте Go.

Go простой и минималистичный язык. Но минимализм не бесплатен: чем больше у вас микросервисов, тем быстрее вы замечаете, что каждая команда пишет собственный DI, собственные middleware, собственные клиенты, собственную работу с БД, собственную обвязку ретраев и метрик. А дальше у вас пять форматов логов, у каждой команды свой retry policy, свой загрузчик конфигов, свои клиенты для Postgres и Kafka и т. д.

Почему так происходит и как можно этого избежать?

В докладе разберём:
- Какие вещи в Java Spring Boot и .NET Aspire уже давно есть, а в Go приходится собирать вручную.
- Почему отсутствие единого пути в Go приводит к зоопарку решений.
- Какие open-source инструменты в Go могут заменить Enterprise-магии, а где все же нужны свои велосипеды.
- Что должна давать внутренняя Go-платформа: стандарты, конвенции, каркас, observability, клиенты, отказоустойчивость и инфраструктурные интеграции.

Если у вас больше 5–10 Go-сервисов, этот доклад поможет избежать хаоса и увидеть, какие платформенные решения нужно строить, прежде чем станет слишком поздно.

ВКонтакте — крупнейшая соцплатформа страны с аудиторией более 90 млн пользователей и инфраструктурой, с историей уходящей в 2006 год. За это время внутренняя архитектура постепенно складывалась в крупную взаимосвязанную систему, усложняющую разработку, масштабирование и внедрение новых функций.

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

Вы узнаете:
1. Почему ВКонтакте требовалась трансформация
2. Почему мы выбрали Go для реструктуризации платформы
3. Как с помощью единой платформы разработки DevPlatform убираем боль операционной сложности микросервисов на Go

Доклад основан на реальном опыте крупного высоконагруженного сервиса России и будет полезен всем, кто работает с legacy-системами и планирует архитектурную трансформацию.

Стандартные механизмы управления памятью в Go оптимизированы для широкого круга задач, однако в сценариях обработки больших массивов данных они могут создавать значительные накладные расходы. В докладе рассматривается опыт разработки и внедрения кастомного аллокатора для системы скоринга, обрабатывающей до 2000 объектов одновременно (за один запрос)

Мы разберем архитектурные ограничения стандартного GC, изучим процесс реализации собственного аллокатора и проведем сравнительный анализ производительности существующих Open Source решений. Слушатели получат критерии выбора между стандартными инструментами, готовыми библиотеками и разработкой собственного решения под специфические нагрузки

TinyGo позиционируется как решение, но насколько он готов к работе beyond the toy projects? Я взял реальный рабочий проект и попытались собрать его.

Сборщик мусора напрямую влияет на скорость работы и предсказуемость приложений. В докладе мы разберём, зачем он нужен, какие подходы применяются в управлении памятью и как устроен garbage collector в Go. Особый акцент сделаем на новом greenteagc, который появился в Go 1.25: что изменилось внутри и какое влияние это окажет на ваши сервисы.

Выход внутреннего проекта в open source — это не просто 'git push'. Это согласования с юристами, вычищение секретов из истории коммитов (23 миллиона утечек в 2024 году — только на GitHub), и осознание того, что ваш код может оказаться под пристальным вниманием людей, которым вы вроде бы и ничего не должны.

Расскажу практический опыт подготовки Go-библиотек к публикации: чем полезны vanity imports, почему 'internal/' в Go работает лучше чем '__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED' в JavaScript. И отдельно — про лицензии и IP-права, чтобы не повторить сценарий Nginx vs Rambler.

Горутины считаются одной из ключевых причин популярности Go: они просты в использовании, легковесны и легко масштабируются. Но за этой простотой скрывается сложный механизм управления стеком.
В этом докладе мы исследуем полный жизненный цикл стека горутины в Go runtime и разберем, какие инженерные решения позволяют Go запускать миллионы горутин без огромных накладных расходов.
Мы поговорим о том, как рождается, растет и уменьшается стек горутины, как runtime управляет его памятью и как эти механизмы помогают писать предсказуемый конкурентный код.

Как работают статические анализаторы? Что такое синтаксическое дерево? Зачем нужна семантическая модель? И как использовать все это для решения практических задач?
Ответим на эти вопросы, поговорим о подводных камнях и узнаем, что нужно, чтобы написать свой анализатор для Golang.

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

Расскажу про ECS архитектуру, ее применение в учетных системах, проблемы современных учетных систем

Многие слышали про гейм-хакеров, реверсеров и читоделов, но мало кто рассматривает Go как инструмент для подобных низкоуровневых задач. В докладе мы разберём популярные в мире game hacking техники.
Вы узнаете:
- Основные концепции game hacking’а.
- Как из Go взаимодействовать с памятью других приложений и системными API;
- Зачем нужна библиотека golang.org/x/sys/windows;
- Как собрать DLL и инжекторовать ее в другие программы;
- Как на практике создаются читы на примере старых игр;
- Где можно легально применить полученные в рамках доклада навыки;

Требования к надежности, безопасности растут, а хочется простое, гибкое и производительное решение для брокера сообщений? Возможно, стоит присмотреться к NATS.
Neural Autonomic Transport System - это высокопроизводительная система обмена сообщениями с открытым исходным кодом, написанная на Go. В процессе доклада рассмотрим его внешнее и внутреннее устройство, сосредоточившись на сути мехнизмов и сущностей. На десерт поделимся секретами правильной настройки прав и нашим опытом по решению проблем репликации очередей для интенсивного потока сообщений. Уверены, что после нашего доклада вы точно скажете "Вау, это реально работает".

Когда в программе возникает потребность во встроенном скриптинге, возникает вопрос о выборе скриптового языка и реализации интерпретатора для него. Скриптинг в программе - это инструмент не столько для разработчиков, сколько для продвинутых пользователей, поэтому надо учитывать особенности этой аудитории. Использование нестандартного или нишевого скриптового языка способно отпугнуть потенциальных пользователей. Python знают все, поэтому выбор именно этого языка представляется идеальным.

Существуют и другие реализации встраивания интепретатора Python в программы на Go. Однако наша реализация обладает рядом существенных преимуществ, которые не встречаются в других реализациях. Среди них: использование системной инсталляции Python, устойчивость бинарных сборок к обновлению системного Python, что сильно упрощает распространение программы, простой API, раскрывающий возможность одновременного использования независимых и изолированных друг от друга экземпляров интерпретаторов Python, автоматическое управление временем жизни объектов Python, видимых на стороне Go с помощью сборщика мусора, гладкая интеграция многопоточности между этими двумя языками.

О том, как нам это удалось и с какими мы столкнулись трудностями и особенностями, будет рассказано в этом докладе.

Доклад о создании MCP-сервера на Go для B2B-платформы Fullinfo: базы компаний, собранной из 1M+ доменов (Tranco). Вместо привычного workflow “открыть портал - запрос - результаты - экспорт в Excel”, есть один запрос в Claude вроде: «найди SaaS-компании в Германии с 50–200 сотрудников» и на выходе готовый список с контактами.
Разберём практическую архитектуру: Go-сервер на mcp-go с набором 9 tools (поиск, AI-поиск, коллекции) и GraphQL-клиент к AWS AppSync. Отдельный фокус на безопасность доступа LLM к данным: граница read/write, мутации заблокированы по умолчанию и включаются только явным флагом --allow-mutations, все запросы логируются. Покажу, как тестировать MCP без Claude через MCP Inspector, и как выстроить TDD для MCP-tools (mock GraphQL client + интеграционные тесты с реальным API; в проекте 100+ тестов).

В high-load микросервисах часто тратятся ресурсы на запросы, которые уже не нужны: клиенты ушли, а обработка продолжается, сжигая CPU и блокируя очереди. Покажу, как на рекламной платформе Magnit OMNI (10+ Golang сервисов, 1000+ RPS, 1+ TB данных/день) мы спроектировали event-driven архитектуру с Kafka/PostgreSQL/Redis, внедрили fraud detection с ML (20GB индекс) и graceful degradation под пиковыми нагрузками.
​
Конкретные техники: perf-оптимизация Golang под SLA, приоритизация очередей (увеличение уведомлений на 50% в XPlanet).

Важно! Для участия требуется ноутбук с предустановленными WireGuard и SSH-клиентами.

В наше время существует очень много практик по предотвращению инцидентов и по ведению процессов вокруг них. Однако никто не умеет учить самому ТУШЕНИЮ инцидентов.

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

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

Формат игры:

Всем участникам выдадут заготовленный стенд, где будет развернут сервис, на который будет подаваться нагрузка, эмулирующая реальных пользователей. В сервисе будут заложены проблемы, которые будут активироваться с течением времени. Помимо сервиса стенд будет в себя включать базовую инфраструктуру, необходимую для выявления аномалий и их устранения: пайплайн доставки кода (GitLab), метрики (Victoria Metrics + Grafana), логи (Vector + Victoria Logs + Grafana).

Go даёт вам безопасность памяти, детектор гонок и одну из лучших в индустрии защиту цепочек поставок. Но модуль с опечаткой (тайпсквоттер) прожил в Go Module Mirror три года. Один запуск goimports подменил crypto/rand на math/rand в rclone - и каждый пароль стал предсказуемым. Компилятор не жаловался.

На этом воркшопе вам предстоит сломать Go-микросервис без единой практики безопасности - раунд за раундом, слой SDL за слоем. Инъекции, гонки, отравленные зависимости, утечка секретов в образе. Каждую уязвимость вы сначала эксплуатируете, потом чините. К концу - у вас понимание, как встроить SDL в CI/CD-пайплайы и тестовая уязвимая кодовая база для обучения команды. Опыт в безопасности не нужен. Нужен ноутбук с Go 1.22+, Docker и готовность увидеть, что же компилятор не проверяет.

Устали поддерживать актуальность Swagger-документации вручную после каждого изменения API? Вам знакомо чувство, когда разработчики работают по устаревшей спецификации?

Я расскажу, как мы внедрили Documentation-Driven подход в продакшене: теперь OpenAPI-спецификация — это единственный источник истины. Из неё мы автоматически генерируем Go-код сервера на любом фреймворке (echo/chi/…), клиентские SDK и даже валидацию для 15+ микросервисов. Мы сократили время на согласование API на 70% и полностью исключили рассогласование кода и документации.

Вы получите готовое пошаговое руководство: от написания первой спецификации в openapi.yaml до интеграции генерации в CI/CD при помощи Docker. Покажу, как за два часа настроить процесс, который сэкономит вашей команде сотни человеко-часов в год.

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

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

Тезисы:
Кодофобия, или страх начать что-то писать свое.
Какие проблемы встречают продуктовые компании в попытках использования смежных стеков.
Культура разработки ПО и откуда она берется в компаниях.
Опыт Рунити: Go-революция и почему кажется, что раньше состаришься чем эволюционируешь.
Еще раз про важность и объем тестирования, а также то — кто это всё-таки должен делать.

Главная цель воркшопа научить вас не только снимать профиль работы, но и интерпретировать результаты. Для этого мы снимем профили cpu/heap, сделаем акцент на mutex contention, разберем mutexprofilefraction и blockprofilefraction.

Чему вы научитесь:
- снимать профили cpu/heap/mutex
- корректно интерпретировать результаты pprof
- читать и понимать flame graph
- находить и устранять узкие места, лишние аллокации и mutex contention

В докладе разберемся с внутренностями проекта Typescript-Go. Поговорим зачем им это было нужно, как они это реализовали и в чем подвох.

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

Цель: максимально быстрый запуск сложных сервисов.
Поговорим про:
1. Observability без лишних трат
2. Бутстрапинг с помощью LLM
3. DDD и чистую архитектуру
4. Полноценную документацию и 100% покрытие логики тестами без лишних трат
5. Недостатки Go, и наши библиотеки для их решения

Тема становится критичной в мире разработки с LLM.

Debugging production latency is frustrating because you need to start tracing "before" the problem happens. You can't predict when a request will take 5 seconds instead of 50 milliseconds. By the time you notice, the interesting execution is gone.

Расскажем о генерации CLI для облачных сервисов на базе OpenAPI. Рассмотрим проблемы ручного написания, сравним фреймворки и подходы к генерации. Определим критерии для API, позволяющие эффективно генерировать CLI. Покажем поэтапную замену ключевых компонентов на сгенерированные, выделим части, которые лучше писать вручную. Оценим затраты на разработку и поддержку итогового решения.

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

Расскажем о своем пути разработки, о своих ошибках и их решениях, о пользователях

С ростом популярности LLM перед инженерами встают задачи управления доступом, контроля затрат и мониторинга использования. За время разработки LLM Proxy мы накопили опыт построения централизованного gateway для работы с языковыми моделями.

Как Go-разработчику создать desktop-приложение с современным UI, без глубокого погружения в экосистему Apple?
Я расскажу про Wails — фреймворк, который позволяет создавать desktop-приложения, используя Go для бэкенда и современные веб-технологии для UI.
Wails позволяет писать бизнес-логику на Go, а UI — на привычных веб-технологиях (React/Svelte), при этом итоговый бинарник в 5-7 раз меньше Electron. Главная магия — автоматическая генерация TypeScript-типов из Go-структур: рефакторишь код на Go, типы в UI обновляются автоматически, никаких рассинхронизаций.

В докладе я поделюсь личным опытом разработки, обсудим:
* почему не Electron / Tauri?
* архитектура Wails: от Go-метода до JavaScript-функции;
* type generation в действии;
* development workflow;

Покажу live-demo реального приложения, разработкой которого я занимался.

Создан прототип OLAP-инструмента, который не боится глубоких и несбалансированных деревьев измерений и с каждым новым уровнем иерархии измерений увеличивает выигрыш в скорости расчетов вдвойне.
https://kobdik.github.io/Cube/speed.html

На основе подготовленных данных о поступлениях и отгрузках материалов разработана интерактивная демонстрация аналитического отчета о движении материалов с вычисленными остатками на начало и конец каждого дня.
https://kobdik.github.io/Cube/flow.html

Для проведения сценарного анализа и оценки последствий задержек поставок материалов, необходимо симулировать ситуации и их последствия в виде потока данных, которые будут загружены в инструмент аналитики. Для этого, на стеке Golang, Kafka и gRPC streaming разработан набор сервисов для генерации имитационных потоков данных движения материалов.

Получилась интересная архитектура на базе обмена унифицированными по структуре асинхронными сообщениями с использованием горутин, каналов, atomic операций, продюсеров и консьюмеров Kafka, потоков со стороны сервера gRPC streaming.

Любой желающий может скопировать себе проект с описанием как запустить в Docker контейнер с Kafka с тремя брокерами, исходные тексты сервисов и команды для их запуска.

Попытайтесь улучшить коды, добейтесь стабильной работы сервисов при уменьшении интервала синхронизирующего таймера сервиса Kronos. На моем ноутбуке мне удалось вписаться в 100 миллисекунд на обработку данных запланированных на день, а это на пике - обработка до 120 заявок.

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

Custom Webpack плагин (100 строк) встраивает переводы прямо в бандлы на этапе сборки.
Проблема: runtime i18n = медленный first render + сложное кэширование. Официальный i18n-webpack-plugin устарел и делает N сборок под N локалей.
Решение: одна сборка → post-processing → compilation.emitAsset генерирует бандлы для всех локалей:
Перехват i18n() вызовов и замена на литералы
Правильный пересчёт contenthash для браузерного кэша
Build time: 45с → 15с (3 локали)
Live demo + bundle analyzer + код на GitHub. Для Go команд с React/Vue фронтами.

При разработке современных приложений мы описываем одни и те же сущности многократно: в API контрактах, в backend-сервисах и в схемах баз данных. Это приводит к дублированию кода, рассинхронизации между слоями и runtime ошибкам в продакшене. Классический пример: добавили поле в базу, забыли обновить API – клиент сломался. Доклад для backend и fullstack разработчиков (Go, TypeScript), работающих в командах от 3+ человек. Разберем практический опыт внедрения кодогенерации на всех уровнях стека: OpenAPI для контрактов между frontend и backend, Protobuf для микросервисов и Sqlc для работы с PostgreSQL. Плюсы: сокращение времени на рефакторинг API, уменьшение количества ошибок типизации. Посмотрим на живых примерах кода и обсудим, когда единый источник правды оправдан, а когда избыточен.

Мы создали свою Saga-библиотеку на Go для полного контроля процесса оркестрации. Поделимся проблемами, с которыми столкнулись в ходе разработки и применения. А главное, сравним наше решение с temporal и разберемся, стоило ли сразу использовать его. В заключение предложим checklist, который поможет вам сделать правильный выбор в пользу своей реализации или готовой платформы.

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

Exciting talk on developing a custom Load balancer in Go using Envoy Proxy. This talk focuses on scalability in a simple and efficient manner which will also help you save on cloud costs. This talk is addresses towards audiences of all kind whether you are new to load balancing or an expert.

Расскажу про библиотеку HSM (Hierarchical State Machine) — о том, как она помогает декомпозировать и организовывать бизнес-логику.
Покажу, как строгая архитектура HSM удерживает разработчиков от смешения контекстов и упрощает тестирование кода.

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

As Go applications grow in complexity, understanding their runtime behavior becomes essential. In this talk, we’ll explore MoniGo: an open-source real-time performance monitoring library for Go that provides instant insights into CPU usage, memory allocation, and function-level metrics.

We’ll walk through how MoniGo captures live service-level and function-level metrics, integrates with UI dashboards, and helps developers identify performance bottlenecks without heavy dependencies.

Attendees will learn:
- How to instrument Go applications with minimal code.
- Techniques to visualize and interpret system and service-level performance data.
- How MoniGo was designed, optimized, and open-sourced for the community.

Whether you're just starting with Go or looking to add observability to your stack, this session will help you understand how to measure what matters - with simplicity, clarity, and open-source spirit.

https://github.com/iyashjayesh/monigo

Your concurrent test passed 47 times. Then it failed. You ran it again. It passed. Congratulations, you now have a slot machine.

Testing concurrent Go code has always meant choosing between slow (sprinkle time.Sleep everywhere) and flaky (accept random failures) or something like a "broken clock" abstraction. Go 1.25's synctest eliminates this choice entirely. Tests that took 20 minutes now run in the blink of an eye. Tests that failed randomly now pass deterministically. Every time!

This talk shows how synctest creates isolated "bubbles" where time is fake, goroutines can be observed at rest, and "this should not have happened" becomes testable.

В последние четыре года наш язык прошел существенный путь: дженерики выступили только началом потока изменений! Только за последние три года мы получили новый циклы for, итераторы, алиасы для дженериков и новый синтаксис встроенной функции new. Кроме этого, произошли существенные изменения в стандартной библиотеке (появилась остановка времени в тестах, интернирование обьектов, слабые ссылки и очистка секретов) а наш рантайм стал быстрее за счёт различных улучшений. Усилился наш тулинг.

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

Сборщик мусора — ключевой элемент, делающий Go простым. Мы доверяем его абстракциям и живем счастливо, в мире где память только выделяется, но никогда не освобождается. Но есть штатные способы "сломать" концепцию бесконечной памяти, о них и поговорим

Утечки горутин — скрытая и опасная проблема в Go-приложениях. Лёгкие и «дешёвые» горутины могут превращаться в долговечно работающие зомби, постепенно увеличивая потребление памяти и нагрузку на CPU. Реальные кейсы, такие как инцидент в Uber (×9 рост памяти и +16% CPU), показывают, насколько дорого обходятся такие ошибки в продакшене.

В докладе мы разберём:
* какие паттерны в Go чаще всего приводят к утечкам горутин;
* реальные случаи из продакшн кода и даже самого компилятора Go;
* как диагностировать проблему с помощью существующих инструментов — например, uber-go/goleak;
* новый Goroutine Leak Profile, уже добавленный в master-ветку Go и ожидаемый в Go 1.26;
* практические рекомендации, которые помогут вам защитить свои сервисы от скрытых утечек.

Доклад будет полезен всем, кто разрабатывает Go-сервисы, особенно в высоконагруженных системах.

В Go, как и во многих других языках, указатели придают коду гибкость, но взамен требуют внимательной работы с ними. И ровно в тот момент, когда Вы подумали, что знаете эту кухню от и до, Go дает Вам новый инструмент: "слабый" указатель.
Что это за подарок судьбы? Для чего он нам нужен и как корректно с ним работать? Где "слабые" указатели нам пригодятся, а где лучше их избегать? Рассмотрим вместе эти вопросы.

Somewhere in your program, there are goroutines that will never wake up. They're blocked on channel sends that will never complete, waiting on mutexes that nobody will unlock. They're not dead, the runtime still knows they exist, but they're not alive either. Your regular goroutine profiler can't tell you which ones they are. A waiting goroutine looks the same whether it's going to wake up in 10 milliseconds or never.

Go 1.26 introduces an experimental goroutine leak detector that changes this. By leveraging the garbage collector's reachability analysis, it can distinguish "waiting for work" from "stuck forever".

Green Tea's insight is elegant: scan spans, not objects. But how do you actually implement that? What data structures track which objects are marked vs. scanned? Why does the ownership protocol use three states? And how did span-based scanning unlock SIMD optimizations that were impossible before?

This talk dissects Green Tea's implementation: the inline mark bits structure, the FIFO span queues, the ownership protocol that prevents duplicate work, and the AVX-512 SIMD kernels in Go 1.26 that use a cryptographic instruction (VGF2P8AFFINEQB) for bitmap expansion. I've read the actual runtime code and understand why each design decision was made.

Хотите создавать моки для интерфейсов без кодогенерации и строить компоненты без шаблонного кода? Посмотрим на мощь type embedding с другой стороны — где за лаконичностью скрываются тонкие, но важные компромиссы.

В Go появился новый тип GC. В рамках доклада разберем его идею и реализацию. Посмотрим на бенчмарки и реальное поведение в проде на высоконагруженном проекте. А также затронем его ограничения и проблемы.

-
-
-

Философия Go изначально отвергала синтаксический сахар в пользу простоты, читаемости и единообразия кода. Однако начиная с версии 1.21 язык стал постепенно вводить выразительные упрощения: улучшенная работа с переменными в циклах, встроенные функции (min, max, clear) и поддержка структурированного логирования.
Продолжение добавления синтаксического сахара может поставить под угрозу ключевое преимущество Go — предсказуемость, — но его отсутствие рискует сделать язык менее конкурентоспособным.
В докладе порассуждаем на тему тенденций "подслащения" Go, рассмотрим возможные проблемы, сравним с другими языками и вместе поймем, к чему это может привести

В докладе рассказывается про внутреннее устройство профиля исполнения языка Go. Что он содержит, как собирается, чем отличается от аналогов, как его может исползовать компилятор.

Go's weak pointer implementation looks deceptively simple: 'Make' and 'Value', that's it. But underneath lies an elegant design involving indirection objects, a handle table, careful GC integration, and an equality guarantee that no other major language provides. How does 'wp1 == wp2' remain true after the object is collected? Why is the indirection object exactly 8 bytes? How does the GC know when to zero the pointer without causing races?

This talk dissects the implementation: the indirection layer that makes equality stable, the handle table that enables efficient lookups, the GC write barrier integration, and why generics were required for a type-safe API. We'll read the actual runtime code and understand the design constraints that shaped each decision.

Domain-Driven Design часто воспринимается как «красиво, но медленно», Но что произойдёт, если придавить DDD-систему высокой нагрузкой?
Я покажу, какие архитектурные решения выглядели правильными, но ломались в проде, как их исправление поэтапно ускоряло систему, и какие практики позволяют писать High Performance DDD на Go — без отказа от доменной модели и без переписывания всего на Rust.

TBD

Go - один из самых лаконичных языков, но у него до сих пор нет тернарного оператора. Почему? Так исторически сложилось, команда языка сознательно не добавляет эту конструкцию. Каждый, кто писал на C, Java, JavaScript или PHP, хотя бы раз ловил себя на мысли: «а вот тут бы пригодился ?: вместо громоздкого if-else».

Доклад посвящён исследованию восприятия идеи добавления тернарного оператора в Go. В рамках работы проведён социальный эксперимент, включающий опросы разработчиков и контрибьюторов языка, сбор аргументов сторонников и противников изменений, анализ существующих proposal’ов и обсуждений в issue-трекере Go. Отдельная часть доклада посвящена практической стороне эксперимента - модификации компилятора, работе с AST и IR-узлами, синтаксическим проверкам и интеграции в IDE на базе форка go-ternary. Разберём, какие сложности возникают при расширении языка и чему подобные эксперименты учат нас о границах и принципах Go.

Go — кроссплатформенный язык. Это качество можно использовать не только для написания классических многоплатформенных приложений, но и как инструмент для обеспечения единства бизнес-логики во всех частях распределённой информационной системы.
В докладе мы посмотрим, как (и зачем) можно, используя WebAssembly и FFI, интегрировать Go в любую часть любого проекта.
Содержание доклада не станет новостью для опытных разработчиков широкого профиля, но может быть интересным для начинающих и для тех, кто пришёл в профессию сразу через веб и в основном пишет под связку «браузер + веб-сервер».

Open source can be more than a side project, it can be a career accelerator. In this talk, we’ll look at how Go developers can treat open source like a supermarket for professional growth: choosing the right “aisles” (projects), picking the “products” (skills and contributions) that matter most, and leaving with a basket full of opportunities. You’ll walk away with practical strategies for making open source work for your career, not just your GitHub profile.

1. Что такое МАС и почему это революционно для Go-разработки
2. Почему Go — идеальный выбор для MAS
3. Готовые решения и фреймворки для Go в 2025 году
4. Пошаговая реализация своего агента
5. Продакшен-кейсы и масштабирование
6. Будущее MAS в экосистеме Go

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

В докладе я разберу ключевые компоненты архитектуры и расскажу о внутренних библиотеках, которые мы создали для решения этой задачи. Мы обсудим возникшие трудности и способы их преодоления.

И главное — всё это реализовано на Go

Конечно, вот 4 ключевых тезиса, сформулированных кратко и энергично:

1. LLM — это инструмент. Понимание токенизации, эмбеддингов и механизма внимания — ключ к созданию работающих агентов, а не просто чат-ботов.
2. Go — идеальный язык для AI-агентов. Его статическая типизация, явная обработка ошибок и простой синтаксис снижают количество ошибок LLM и предсказуемы для модели.
3. Агент = мозг + руки. Успех заключается в архитектуре, где LLM (мозг) управляет инструментами (руки) для работы с Jira, Git и кодом через цикл рассуждений.
4. Это уже рабочая реальность. Мы строим агента, который от тикета в Jira доходит до готового Pull Request, автоматизируя рутину и позволяя инженерам фокусироваться на сложных задачах.

Вы когда-нибудь хотели понять, как и над чем вы на самом деле работали, пока копили гигабайты чатов с AI-ассистентами? Расскажу об инструменте, который анализирует историю диалогов, группирует похожие задачи и генерирует структурированный отчёт: что вы просили, что делал агент, какие технологии использовались и какую ценность вы создавали. По сути, это способ "вытащить ваш вайб" из хаоса диалогов в понятный отчёт.

Codegen-инструменты (sqlc, protoc, oapi-codegen, go-swagger, mockgen, etc) дают воспроизводимый код на основе контрактов, LLM-ассистенты вроде Cursor и Copilot — гибкость и скорость. В докладе сравним два подхода на примерах Go-сервисов: базы данных, API и моки. Обсудим оси сравнения — типобезопасность, стабильность diff, поддерживаемость, скорость разработки — и предложим гибридную стратегию: что генерировать контрактно, а где разумно доверять LLM.

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

Несмотря на довольно удобный встроенный механизм написания тестов в Go, процесс этот очень однотипен - часто приходится описывать одну и ту же структуру множество раз, а секции setup и teardown каждый раз необходимо долго расписывать. На конкретном примере посмотрим, как можно интегрировать локальную большую языковую модель (LLM) в рабочий процесс и автоматически создавать базовый каркас тестов.

Если ваш проект создавался как PoC, а потом перерос в нормальный рабочий продукт - то этот доклад для вас. Почти однозначно у вас есть огромный объем кода и 0 unit-тестов. Доклад будет полезен всем, кто стремится оптимизировать процесс тестирования, но опасается потерять в скорости разработки и развития продукта.

Skills, Workflow, MCP - мы уже слышим эти слова буквально из под каждого утюга, но вот вы задумывались а что если не рассматривать их отдельно? Суть в том, что если вы возьмете AI модель (от GPT5 до Gemini) - то заметите, что основные их "начальные" идеи просто вести дилаог изменеились в сторону агентских функций, но как это все работает? Как строятся графы взаимосвязей? Как создать агента, а не просто чат бота? В общем, обо всем по порядку :)

Управление подключениями сетевых и локальных дисков в облакe - сложный и интересный процесс, который имеет массу разных решений. В данном докладе я расскажу, как это делаем мы в новой облачной платформе MWS Cloud Platform, с какими трудностями сталкиваемся и какие решения принимаем, чтобы достичь надежной, безопасной и отказоустойчивой системы. Посмотрим как на верхнеуровневую архитектуру нашей системы, так и заглянем в глубь наших сервисов и посмотрим на такой подход, как реконсиляция и то, как мы его реализовали в Go в наших демонах, кроме этого обсудим наливку дисков и создание снепшотов, а так же зачем мы сделали собственный механизм работы с тасками и как это у нас реализовано.

Так вышло что на go сейчас переписывают все подряд.
Очень часто это что-то что связано с большим количеством пользователей, сетевой активностью, интерактивностью и т.д. и не всегда такие переписывания заканчиваются так хорошо как ожидалось.
Любая достаточно сложная распределённая программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Erlang.
В мире Erlang/Elixir десятилетиями копилась мудрость под названием OTP - Open Telecommunication Platform. Она написана кровью, потом и слезами инженеров.
OTP - это в первую очередь набор принципов и паттернов проектирвоания и только потом библиотека.
Рассматриваем ваши проблемные кейсы и выясняем какие из принципов OTP могут помочь в вашем случае.

Расскажу о том, как не завязнуть в болоте разработки по пути к релизу нового продукта

Наш отдел состоит из 3х команд, и у каждой своя специфика работы с данными. Это привело к различным подходам к структурированию пакетов в разных репозиториях. В новых сервисах хочется сделать лучше, но без строгого контроля получается только хуже. Документы с договоренностями никто не смотрит ни при разработке, ни тем более на ревью. Все это приводит к необходимости жесткой структуры проекта и автоматизации проверок требований.

В своем докладе я расскажу про:
- как мы пришли к единому шаблону архитектуры;
- что мы выбрали и почему;
- почему договоренности “на словах” не работают;
- обзор инструментов для проверки архитектуры;
- наш пример с arch-go.

Что делать, если стандартные инструменты уже не справляются с ростом сервисов в монорепозитории так же хорошо, как раньше ? Уходить от монорепозитория, писать свой туллинг или использовать готовый инструмент ? Поговорим о том, почему не обязательно разделять монорепозиторий, что такое Bazel build и как он может помочь в эксплуатации большой кодовой базы.

Разберём, какие компоненты Kubernetes пишут на Go и как устроена работа типичных сервисов в кластере. Покажу, как выглядит продвинутый CI/CD с канареечными релизами и progressive delivery. Поделюсь реальными граблями, с которыми мы столкнулись при разработке решения в области безопасности контейнерных сред — от проблем Tetragon и eBPF в k3s до особенностей асинхронной природы Kubernetes. Доклад подходит и для новичков, и для разработчиков, которые уже работают с Kubernetes, но хотят понять его глубже.

Это обзорный доклад, в котором будет рассказан опыт нашей команды в написании компилятора/транслятора для языка серилиазации данных TL (похожего идейно на Protobuf) и его rpc. Из него вы узнаете:
* Основы написания компиляторов, а также плюсы и минусы написания их на Go
* Как поддерживать такие решения и расширять их функционал
* Как почти незаметно для клиентов менять почти все что угодно (наш опыт в этом)

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

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

На этом докладе мы разберем директиву компилятора //go:linkname — мощный инструмент, позволяющий обходить запреты языка и получать прямой доступ к приватным переменным, функциям и методам любых пакетов.
Мы рассмотрим механику и примеры использования, разберём реальные кейсы, где этот приём даёт прирост производительности, и как его используют популярные пакеты.
Вы узнаете, почему команда языка была вынуждена ввести ограничения на использование go:linkname, что это за ограничения и какие есть известные нарушители из hall of shame.

Обычно мы не думаем о сборщике мусора – он работает где-то в фоне, и этого вроде бы достаточно. Но по мере роста нагрузки, объёма данных и количества ядер в системе, даже такая "мелочь" может внезапно начать сдерживать производительность.

В Go 1.25 появился экспериментальный Green Tea GC – попытка по-новому взглянуть на то, как эффективно управлять памятью в современных системах.

В этом докладе разберёмся, почему классический GC начал "буксовать", как Green Tea меняет подход к сканированию памяти, причём здесь кэш-локальность и как всё это отражается на реальной работе приложений.

Посмотрим на исходники, бенчмарки, включим экспериментальный флаг и обсудим, когда эта штука действительно помогает, а когда – нет.

Даже если вы не пишете свой runtime, понимать что происходит под капотом все равно полезно. Потому что иногда именно там прячутся лишние 30% CPU.

Про компилятор Go часто можно услышать: «он недостаточно умный, вот в Rust или C++ оптимизации — а в Go что?». Но так ли это на самом деле? Действительно ли Go-компилятор безнадёжен, или за простотой скрывается вполне серьёзный арсенал?

В докладе мы разберёмся, что на самом деле делает компилятор Go, и какие оптимизации происходят незаметно для разработчика:
* посмотрим, как выглядит полный flow оптимизаций;
* вспомним про классические приёмы: inlining, escape analysis;
* разберемся что такое SSA, как оно устроено и какую пользу он принес;
* оценим весь масштаб constant folding;
* поймем есть ли оптимизации циклов: loop unrolling, loop invariant code motion и vectorization;
* сравним наш компилятор с более агрессивными, например из C++;
* обсудим, почему часть оптимизаций так и не добавлена (или добавляется крайне осторожно).

В завершение обсудим: действительно ли компилятор Go так уж «глуп», и почему авторы языка могут намеренно сдерживать его развитие в сторону сложных оптимизаций.

Что делать, когда хочется использовать современный инструмент кодогенерации SQLC для работы с YDB, но он поддерживает только PostgreSQL, MySQL и SQLite? В этом докладе я расскажу трехлетнюю историю о том, как наивная идея затащить YDB в SQLC превратилась в масштабный проект по переписыванию парсера YQL с нуля.
Вы узнаете, какие технические препятствия встретились на пути — от устаревшей грамматики ANTLR v3, не способной генерировать Go-код, до отказа мейнтейнеров SQLC принимать четвертую базу данных в апстрим. Я покажу, как одна задача породила цепочку из нескольких проектов: переписывание ANTLR-грамматики YQL (PR студента на 14К строк), внедрение нового-парсера в продакшн YTSaurus, создание автодополнения для веб-интерфейса и CLI, и наконец — реализацию полноценной поддержки YDB в SQLC с генерацией кода для database/sql, нативного ydb-go-sdk.
Доклад будет полезен тем, кто сталкивается со сложными техническими проектами, требующими долгосрочного планирования и координации между разными командами. Это история о том, что иногда для решения одной задачи нужно сначала решить несколько других — и как превратить это в успешный опенсорс-проект с около-нулевыми затратами.

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

Но что случается, когда собственные технологии встречаются с реальным хайлоадом? Что делать, если мы хотим хранить данных больше, чем позволяет собственный стек технологий? Что делать, когда данные оказываются куда более уникальными, чем закладывалось? Что делать, если человеческий фактор сводит на нет плюсы технологий?

Я расскажу, как мы в целом переосмысливали процесс трейсинга, как выстраивали расследование и выявляли проблемные места, с какими вызовами мы столкнулись при миграции с schemaless на schemafull базу данных, как построили процесс бесшовного перехода, почему отказались от старой парадигмы и какие уроки вынесли из этого многолетнего путешествия.

В асинхронных интеграциях с внешними сервисами часто полагаются на очереди, ретраи и ключи идемпотентности, ожидая, что этого достаточно для надёжной обработки событий.
На практике такие решения дают ложное ощущение exactly-once и ломаются в моменты гонок, дубликатов и несогласованного порядка обновлений.

В докладе я разбираю опыт построения онлайн-системы обработки десятков тысяч событий в сутки с требованиями к консистентности в пределах нескольких секунд. Я покажу, почему at-least-once обработка оказалась недостаточной, где именно ломаются классические подходы и как мы пришли к управлению версиями сущностей и порядком выполнения задач на уровне бизнес-логики.

Доклад основан на реальных прод-инцидентах: дубликатах событий, гонках задач в очереди, неконтролируемых ретраях и рассинхронизации данных с внешними провайдерами. Я расскажу, какие инженерные компромиссы пришлось принять, от каких "правильных" решений отказаться и какие подходы в итоге позволили системе перестать зависеть от поведения внешних сервисов.

Команда корпоративной почты Mailion была уверена, что архитектура спокойно выдержит 85 000 пользователей: Go быстрый, MongoDB тянет, функционал стабильный. Но реальная нагрузка пришла раньше, чем мы успели «оптимизировать потом», — и буквально размазала все наши предположения. 
Выяснилось, что MongoDB стала главным тормозом, утечки памяти прятались в тех местах, которые считались самыми безопасными, сеть была перегружена избыточными взаимодействиями, а единая точка управления объектами оказалась идеальным архитектурным антипаттерном, который с ростом пользователей нагружал всю систему.
Этот доклад — честная анатомия наших ошибок и переоптимизаций, рассказ о том, как мы сами устроили себе архитектурный ад, как выбирались из него и какие выводы сделали. Если вы хоть раз думали «потом оптимизируем» — приходите посмотреть, как выглядит это самое «потом» на реальных метриках, графиках и живом продакшене.
В докладе — честная история о том, что пошло не так и как мы это исправляли.
Вы узнаете:
как pprof помогал локализовать узкие места;
почему MongoDB стала бутылочным горлышком;
как мы нашли и устранили утечки памяти;
каким образом избыточные сетевые взаимодействия замедляли всю систему;
и как единая точка управления объектами создала неожиданный каскад проблем.
Главный вывод: откладывать производительность «на потом» нельзя. Мы поделимся конкретными инструментами, метриками и решениями, которые помогут добиться устойчивых 85 000 пользователей (или больше) без жертв в функциональности.

В докладе я расскажу, как мы строили видеоплатформу уровня TikTok на Go: с загрузкой больших видеофайлов, асинхронным транскодированием, событиями в Kafka и высокими требованиями к надёжности.

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

В докладе будут рассмотрены:
- возобновляемые загрузки видео с помощью протокола TUS,
- гарантированная доставка событий через Outbox-паттерн,
- многоэтапное восстановление процессов транскодирования,
- эволюция кэша от in-memory к PostgreSQL с placeholder-паттерном,
- retry-декораторы для работы с транзитными ошибками БД,
- упрощение интеграции через единый SDK.

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

Казалось бы, шифровать поток данных в Go — задача решённая. Но когда нужно добавить данные в конец зашифрованного файла и при этом не сломать существующий поток, готовых решений вдруг не оказывается. Так появился rusjoan/streamcrypt — библиотека, которая позволяет «обернуть» любой io.Reader/io.Writer в AES-GCM-шифрование без аллокаций и с возможностью дозаписи.
В этом докладе я покажу, как из небольшой утилиты выросла полноценная open-source библиотека, как искать и устранять “призрачные” аллокации, почему binary.Write может подставить, и как оформить свой первый open source-проект так, чтобы им хотелось делиться. Если вы хотите глубже понять, как устроен потоковый ввод-вывод в Go или планируете выложить свою первую библиотеку — этот доклад для вас.

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

В докладе разберём мутационное тестирование в Golang с практической точки зрения: как его внедрять в существующий проект, как интерпретировать mutation score и как использовать его в повседневной разработке. Обсудим влияние на CI, стоимость запуска, ограничения подхода и место mutation testing рядом с coverage - как метрики, отвечающей на другой вопрос о качестве тестов.

Иногда фича должна быть «уже завтра», а тесты ещё не прогнаны, стейджинг не работает и дедлайн поджимает.
В таких ситуациях инженеру нужно не просто писать код, а защищать качество продукта.
Я расскажу, как мы превратили хаотичные выкатки в управляемый процесс: формализовали стоп-факторы перед релизом, встроили QA во временные оценки и научились говорить с бизнесом на языке данных, а не ощущений.
Доклад — реальная история Go-команды, которая научилась держать качество под контролем даже в условиях горящих сроков.

Мы делаем Host-Based Firewall, у нас возникли сложности с его тестированием: в реальном сетевом обмене всегда участвует как минимум два актора. Чтобы достоверно проверять правила, нам нужен был способ воспроизводить сетевые сценарии между этими хостами автоматически.

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

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

Покажу набор правил на базе go/analysis, который автоматически ловит типовые прод‑ошибки: отсутствие таймаутов в HTTP, пропущенные дедлайны, крипто‑антипаттерны, SQL в handler’ах и утечки PII в логах. Разберу, как писать low‑noise правила, интегрировать их в golangci‑lint/CI, измерять precision/recall и развертывать через baseline с постепенным ужесточением гейтов.

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

В большой инфраструктуре неизбежно возникает желание научиться контролировать сеть, строить карту доступов, давать и отзывать их быстро, удобно и прозрачно для пользователей. Мы решили эту проблему , сделав Host Based Firewall, фильтрующий трафик прямо на хостах, попутно построив карту трафика с гранулярностью до процесса.

A spinlock is the difference between pacing by the door versus taking a nap while waiting for a package. One burns CPU cycles. The other yields to the scheduler. Both have their place, but Go deliberately hides spinlocks from you.

This talk explains the core trade-off between spinning and parking, reveals the hidden spin within a Mutex, and explores why Go's runtime uses a "spinbit" design that allows only one goroutine to spin at a time.

You'll learn when spinning wins, when it's catastrophic, and why adaptive hybrid locks beat both pure approaches.

Comparing two identical 1MB strings takes 1.3 milliseconds. Comparing two 'unique.Handle[string]' values takes 0.31 nanoseconds. That's 4.1 million times faster.

The 'unique' package: a standard library solution for value canonicalization (also called interning). This talk explores the problem it solves, how it works internally with GC-integrated weak pointers, and when you should (and shouldn't) reach for it.