Go *

История разработки Ptah: как небольшой Go-first инструмент для миграций собственной базы данных постепенно превратился в полноценную open-source систему управления схемой БД. Причины появления проекта, какие архитектурные решения пережили весь проект, зачем понадобилась совместимость с Atlas, к чему привёл конфликт с его разработчиками, как это повлияло на развитие Ptah и что в итоге представляет собой решение сегодня.

Несколько месяцев назад мне понадобилось заключить договор с Леноблводоканалом. Казалось бы, обычная бюрократическая задача: отправил документы, получил ответ, подписал договор. На практике ответа долго не было. Юриста у меня не было. Зато был AI.

Я описал ситуацию, приложил документы и попросил помочь разобраться, какие у меня вообще есть варианты. В результате подготовил две жалобы в УФАС. Через некоторое время история сдвинулась с места, и договор со мной в итоге заключили.

Не хочу делать из этого вывод в духе «ChatGPT заменил юриста». Наоборот. Когда я позже посмотрел на этот процесс уже как backend-разработчик, самым интересным оказалось другое:

обычный чат — довольно плохая архитектура для решения подобных задач.

Именно из этого наблюдения появилась идея небольшого SaaS-проекта.

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

Зато много статей про диагностику утечек горутин, профилирование памяти, внутреннее устройство рантайма, особенности современных процессоров и эксплуатацию высоконагруженных PostgreSQL‑кластеров.

В 2026 году экосистема Go значительно «повзрослела». Сама спецификация языка уже стабилизировалась, и фокус инженерного внимания сместился в сторону эксплуатации (Production Engineering) — предсказуемости памяти, автоматической диагностики рантайма, управлению ресурсами железа и устойчивости баз данных под высокой нагрузкой.

На связи команда Golang‑инженеров Авито, а ниже — несколько публикаций, которые хорошо показывают этот сдвиг.

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

Как открыть транзакцию на уровне use case, передать её репозиториям без зависимости бизнес-логики от ORM и правильно обработать вложенные вызовы.

В Go 1.27 переделали аллокацию мелких объектов. По бенчмаркам с release notes ожидаемое ускорение может составлять до 30%. Разбираемся так ли это на самом деле, что в итоге сделали и почему эта фича должна была войти в релиз 1.26, но не вошла.

Мысль о заработке с помощью ИИ не даёт мне покоя уже три года. Когда слово “агентные” можно было услышать только в интервью Сергея Брина, а опенсорсные модели годились только для adult-ботов, я создал своего первого агента с помощью nerve-cli. Это утилита, которая запускает запросы модели в цикле с доступом к утилитам и промптом-целью. Агент сам писал скрэпер новостей, проводил анализ настроений и выдавал рекомендации по инвестициям. По сути, это был прототип News Sentiment Trading.

Эта система выдавала конечный результат 1 раз из 10, и лишь один из 10 конечных результатов я брал в работу.

Но в 2025-м году с рынком что-то случилось. Новостной анализ перестал приносить желаемый результат. Вооруженный нейросетями (Claude, DeepSeek, Qwen, и бесплатные от Opencode) я принялся искать рабочий подход.

В данной статье расскажу про проект logporter, который для меня полностью заменил решение от Google для централизованного и полнофункционального мониторинга контейнеров Docker.

Экспортер написан на Go и совмещает функции сборщика метрик, логов, проверки обновлений образов и встроенной панели мониторинга в одном легковесном образе.

Три способа тихо сломать приложение сборкой зависимостей: два пула к базе, не тот кэш, разъехавшиеся ветки конфигурации. Компилятор их не ловит — типы верные. Рантайм-контейнеры ловят половину и приносят свои отказы. Про diogen — compile-time DI для Go: внедрение зависимостей на этапе компиляции, обычный Go-код на выходе, без рантайм-контейнера и без рефлексии.

Один и тот же JSON может привести систему к разным выводам. Валидатор пропустит поле, которое Go‑сервис спокойно прочитает, nil‑слайс превратится в неожиданный для клиента null, а ошибка в имени параметра останется незамеченной до самого продакшена.

Разбираем пять случаев, где поведение encoding/json в Go способно создать расхождение между компонентами системы, и смотрим, что меняет переход на encoding/json/v2.

Привет, Хабр! Эта статья посвящается важной теме работы в многопоточной среде. Для безопасной работы с одним ресурсом из разных горутин разработчик должен быть уверен в безопасности и обособленности действий, чтобы не создать ситуации, в которых "гонки данных" (data race) ломали бы важную логику и создавали коллизии данных.

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

Что происходит, если строить каталог на миллионах товаров не вокруг PostgreSQL и Elasticsearch, а вокруг mmap, собственных индексов и zero-allocation JSON? Разбираю архитектуру, компромиссы и реальные результаты на работающем агрегаторе: около 50 000 RPS и миллисекундные ответы.

Когда decode(encode(x)) == x недостаточно

С сериализацией всё вроде бы просто: есть значение x, мы превращаем его в байты, передаём куда-то ещё, а потом восстанавливаем.

decode(encode(x)) == x

Если получилось — значит, сериализация работает. По крайней мере, так кажется. Но что именно означает ==?

Если два указателя после декодирования указывают на независимые объекты с одинаковым содержимым — значение сохранилось или нет? Если два slice содержат те же байты, но больше не используют одну backing array? Если объект ссылался сам на себя, а после восстановления цикла уже нет? В какой-то момент оказывается, что сохранить данные — ещё не значит сохранить значение.

А затем возникают следующие вопросы: что именно должно быть частью wire-представления, может ли одно значение иметь несколько корректных представлений и сколько ресурсов decoder вообще обязан потратить на восстановление недоверенного входа?

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

Для одной научно-исследовательской задачи мне понадобился массив на 160 ГиБ в Go с максимально быстрым случайным доступом на чтение, а также с быстрым захватом и освобождением памяти при создании/уничтожении массива.

Стандартные методы работы из Go не выжимают максимума, поэтому выходом стал выделенный сервер и Huge Pages размером 1 ГиБ. Тесты по сравнению со стандартным подходом Go и любопытные детали — в статье.

Всем привет! Меня зовут Михаил Голубев, и я работаю в команде Kubernetes Security, MWS Cloud Platform. В этой статье я расскажу об одной попытке оптимизации: как мы залезли под капот CEL и Protobuf, чтобы научить интерпретатор читать данные из бинарного формата на лету без полной десериализации, и почему в итоге от этого кода пришлось отказаться.

Почему мы вообще этим озадачились: в одном из наших микросервисов реализовано сканирование приходящих событий по k8s-манифестам. Событий летит много, а обрабатывать их надо быстро, так что, чтобы минимизировать сетевой трафик и снизить нагрузку на инфраструктуру, в качестве основного формата передачи данных мы первоначально решили использовать Protobuf, он значительно компактнее JSON.

Далее эти данные проходят через различные валидации и проверки. Для описания и выполнения таких политик мы используем CEL — наподобие Kyverno или нативных k8s Validating (и Mutating) Admission Policies. Вот тут-то Protobuf и CEL встретились, и эта встреча оказалась не такой гладкой, как мы рассчитывали, — об этом подробнее ниже.

С документацией к API есть две крайности, и обе плохие: написанная руками врёт через полгода, сгенерированная целиком стирает всё осмысленное, что в неё написали.

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

К вам пришёл кандидат, который идеально проходит по всем критериям, но вам нравится давать необоснованные отказы? Или вам надоели AI-суфлеры от волков, поэтому вам нужна детекция кандидатов жуликов?

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

Всем привет!

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

Когда рекламный баннер «Пройди Тест по Go от Selectel» всплыл уже четвертый раз за день — я сдался. Нажал и пошёл проходить тест — несмотря на аннотацию уровень оказался очень «базовым» так что через несколько минут я завершил его всего с одной ошибкой.

Это событие не стоило бы упоминать — но «впечатлило» оформление и воплощение теста — как можно видеть ниже — из‑за неаккуратности составителей даже и ответ где‑то иной подходит. Попытался об этом написать приватно, почтой — но, кажется, безуспешно. Может заметку на Хабре заметят быстрее?

Go показывает стабильную память, heap-профиль молчит, а Kubernetes всё равно убивает под по OOM. Разберём, откуда берётся это расхождение, как на поведение под лимитами влияют cgroup, GOMAXPROCS и GOMEMLIMIT и что изменилось в последних версиях Go.