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

Что, если Kubernetes для вас — не среда деплоя, а сам продукт? В этом питче я расскажу, как устроена разработка Kubernetes-платформы Deckhouse: какие задачи мы решаем, почему пишем на Go и как выглядит работа, когда ты строишь платформу, которая упростит жизнь другим инженерам.

Вы узнаете, как мы собираем готовый продукт из набора разрозненных Open Source-проектов: где приходится «подпиливать», где — активно контрибьютить в upstream, а где — писать свои контроллеры, операторы и инфраструктурную логику с нуля.

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

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

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

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

Как собрать свое облако, способное масштабироваться под любые нагрузки?

Погрузимся в связку KVM, Qemu и Go для управления виртуализацией, развернем отказоустойчивое хранилище на Ceph и научимся управлять ресурсами через механизм реконсиляции. Узнайте, какие инструменты и подходы превратят ваш сервер в мощное облако — без магии, только код и железо.

Выход внутреннего кода в Open Source — это не просто «git push». Это юристы, лицензии, вычищение секретов из истории коммитов (23 миллиона утечек на GitHub за 2024 год), синхронизация внутренних и внешних репозиториев и документация, которую кто-то все-таки должен написать.

На практическом опыте выведения Go-библиотек Gaijin Entertainment в Open Source расскажу обо всем пути: от согласования с юристами и выбора между CLA и DCO до настройки internal-first-пайплайна, vanity imports и управления видимостью через «internal/». Отдельно — про то, как не утонуть в поддержке, когда проект набирает популярность, и почему думать о закате проекта стоит еще до его запуска.

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

Многие слышали про гейм-хакеров, реверсеров и читоделов, но мало кто рассматривает 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, с помощью сборщика мусора, гладкая интеграция многопоточности между этими двумя языками.

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

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

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

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

Важно! Для участия в данном формате с собой необходимо иметь ноутбук.

Debugging production latency is an information problem. By the time you know something went wrong, the execution that caused it is gone. Traditional profiling asks you to predict when to look. FlightRecorder asks a better question: what if you were always looking?

FlightRecorder writes trace events into a ring buffer at 1-2% CPU overhead, goroutine state changes, blocking, mutex contention, and scheduling delays. When a request breaches P99 or an error spike hits, you snapshot. This talk covers FlightRecorder's architecture, why pprof can't explain most latency, the MinAge/MaxBytes tradeoff, and automatic snapshot patterns from production deployments.

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

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

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

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

В докладе мы разберем:

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

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

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

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

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

Отдельная часть доклада посвящена практической стороне. Разберем, какие сложности возникают при расширении языка и чему подобные эксперименты учат нас о границах и принципах 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.

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

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

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

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

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

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

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

Часто думают, что главная работа программиста — это реализация функциональности. Программа должна работать и делать то, что от нее ждут. И это, конечно, правда! Но не вся…

Успех проекта часто определяется не только тем, «что делает программа», но и »как именно делает», т.е. нефункциональными характеристиками. А их реализация зависит от того, насколько грамотно и полно были собраны как раз НЕфункциональные требования. Если на этом месте у вас возникают вопросы: «с чего бы это?», «что это такое?», «мои ли это заботы?», и даже «да зачем их собирать?» — этот мастер-класс для вас.

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

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

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

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

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.