Go *

Несколько месяцев пилю embedded P2P-мессенджер на Matrix-протоколе как личный pet-проект в свободное от основной работы время. Стек: форк Dendrite (Matrix homeserver на Go), Pinecone overlay routing от matrix.org research, gomobile bind для упаковки в .aar и .xcframework, modernc.org/sqlite вместо CGO-варианта (иначе gomobile капризничает). Не туториал и не “hello world на gomobile”, а серьёзная архитектурная амбиция в свободное время. Делюсь reasoning’ами почему такие архитектурные выборы и где они начинают течь.

Без обещаний неубиваемости. Проект в активной разработке, на этапе интеграции в клиентское приложение поверх Rust SDK matrix.org. Цифры приведу с явной маркировкой “где замерено на моём стенде, где плановая оценка, что ещё не проверено”. Production-NAT-кейсы (CGNAT, реальные мобильные сети) - впереди в следующем рывке. Если что-то принципиально новое всплывёт - напишу продолжение.

После выхода новой локальной модели Qwen 3.5 мне захотелось проверить не абстрактный бенчмарк, а более приземленную вещь: можно ли отдать маленькой локальной модели обычную задачу из backend-разработки и получить рабочий результат.

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

Про подход, железо и выводы подробно описано в статье.

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

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

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

Я написал gcscope — терминальный визуализатор сборщика мусора для Go. Он показывает, как ведёт себя GC в реальном времени: насколько часто он запускается, как меняется потребление памяти, есть ли моменты, когда паузы становятся заметно длиннее обычного. Работает с любым Go-приложением без правок в коде, и вы сразу видите наглядные графики вместо потока логов. А ещё можно сравнивать поведение своего сервиса до и после изменений.

Эта книга для тех, кто уже пишет на Go и понимает синтаксис, но хочет прокачать знания в вопросе выбора алгоритмов под свою задачу. Книга «Алгоритмы на языке Go» написана именно для такой аудитории. Это первая специализированная русскоязычная книга по алгоритмам с реализацией на Go. Она не очень объемная, — всего 192 страницы, 8 глав с конкретными примерами кода, —  по-своему, это ее  плюс, т.к. сейчас никто из разработчиков не читает толстенные «кирпичи» без крайней необходимости.

Большинство медиа-библиотек для Go рано или поздно упираются в одну и ту же проблему.

У них нет собственного декодера.

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

На этапе разработки всё работает. Затем начинается развертывание.

И внезапно вы отлаживаете отсутствующие DLL в Windows, несовместимые версии FFmpeg в Linux, различия версий из Homebrew на macOS, образы контейнеров без нужных библиотек или продуктовые серверы, где рядовое обновление пакета неожиданно ломает обработку медиа.

Локальные LLM сейчас — это действительно мощный инструмент. Они уже вплотную приблизились к проприетарным моделям вроде Claude, особенно в задачах кодинга. Я сам активно использую локальные модели для разработки на TypeScript и Go.

На данный момент самая интересная модель для моего стека — Qwen3.6-27B. Но один только выбор хорошей модели ничего не гарантирует. Без правильных параметров вы не получите ни скорости, ни качества.

В этой статье я расскажу, с какими конкретно параметрами запускаю Qwen3.6-27B в llama.cpp (мой текущий фаворит среди бэкендов), какие метрики считаю важными, и как нашел баланс между скоростью, стабильностью и качеством.

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

Держать proto-контракты в одном репозитории удобно, но подключать их целиком в каждый сервис — не очень. Разберём, как автоматически генерировать Go-стабы из proto-файлов, версионировать их как отдельные Go-модули и публиковать через GitLab CI/CD. Бонусом — swagger-документация и GitLab Pages.

Мне нравится чистый SQL.

Не «нравится, потому что пришлось», а правда нравится. В хорошем SQL‑запросе видно, что происходит с данными: откуда берём, как фильтруем, где соединяем, что агрегируем и в каком порядке отдаём наружу.

Но как только в API появляются фильтры, сортировка, пагинация и отдельный COUNT(*) с тем же WHERE, чистый SQL быстро обрастает ручной бухгалтерией: args, placeholder«ы, fmt.Sprintf и копирование условий между запросами.»

В какой‑то момент я понял, что меня раздражает не SQL. Меня раздражает работа вокруг SQL.

Так появился qrafter — небольшой type‑safe SQL query builder для Go: без ORM, без codegen, с типизированными колонками, зависимым от диалекта рендером и обычным SQL + аргументами на выходе.

Я пилю VantageDNS, privacy-focused recursive DNS-резолвер с фильтрацией. Edge-фронт на Go, 10 нод по миру, миекговский miekg/dns под капотом. На каком-то этапе у меня закончились отговорки, и пришлось писать DNSSEC validator. Своими руками. Ночью. Под кофе восьмой кружки.

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

eBPF называют «безопасным по умолчанию». Но что, если это не так?

Все хвалят eBPF за «безопасность и изоляцию». Но что если данные из вашей eBPF-мапы может прочитать любой процесс с правами root?

Я не буду учить писать свой eBPF-хелпер. Я покажу практический пример демонстрации этой уязвимости.

Пора разобрать вопрос, о котором часто молчат: почему данные из eBPF-мап могут быть доступны не только вашему агенту.

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

Если честно, то лично я считаю, что это не просто «альтернатива», а предпочтительный выбор по умолчанию для большинства API (где конфигурация — это именно данные).

По большому счёту, паттерн Resolvable Config Struct просто наводит порядок в тех структурах Config и Options, которыми мы все пользуемся на порядок-два чаще, чем Functional Options. Чтобы его внедрить понадобится лишь минимальный рефакторинг, потому что всеми элементами этого паттерна мы и так постоянно пользуемся, просто сейчас там бардак, в который нужно добавить немного строгости чтобы стало намного лучше.

Мой поинт не в том, что Functional Options были ошибкой. Скорее это был разумный ответ на плохие конструкторы и наивные Config-структуры образца «просто положим всё в поля и как-нибудь разберёмся». Но сегодня есть решение получше, и его стоит внедрять.

Привет. В предыдущих статьях этого цикла мы разбирали, как Kubernetes-объекты читаются (первая — informer и кэш в controller-runtime) и записываются (вторая — Server-Side Apply, patch’и, managedFields). Сегодня — про их жизненный цикл.

Между kubectl apply и появлением объекта в etcd проходит целая цепочка: admission chain, мутирующие и валидирующие вебхуки, schema-валидация, встроенные плагины. Между kubectl delete и реальным исчезновением объекта может пройти от миллисекунд до часов — в зависимости от того, какие на нём финализаторы и какая стратегия каскадного удаления выбрана. Механизм при этом универсален для любого ресурса: Pod, Deployment, ваш CRD — жизненный цикл у всех один.

В этой статье я постараюсь ответить, что происходит с объектом от его рождения до смерти. И отдельно поговорим про другое измерение — эволюцию его API-схемы.

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

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

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

io_uring продавали как убийцу epoll. На деле на HTTP keep-alive разница 0-15%, иногда не в его пользу. Но на NVMe с queue depth 128 - в 3 раза быстрее. Честный разбор с бенчмарками, реальными граблями (SQPOLL, cancel race, partial recv) и почему Google отключил io_uring в ChromeOS.

Когда сервис падает с too many open files, первое желание — проверить ulimit -n и поднять лимит повыше. Но в Linux эта ошибка редко сводится к одной настройке: в игру вступают файловые дескрипторы, сокеты, лимиты процесса, настройки контейнерного рантайма и поведение самого приложения.

В статье разбираем, что на самом деле означает EMFILE, где смотреть реальные ограничения в Kubernetes и как отличить нехватку лимита от утечки, которая рано или поздно снова уронит прод.

В прошлой статье я рассказывал, как мы встроили VLESS + Reality прямо в наше iOS-приложение через sing-box, чтобы обход блокировок был не задачей пользователя, а деталью реализации. Если коротко: TLS-рукопожатие проксируется на посторонний крупный сайт, активный пробинг упирается в этот сайт, IP относимся как к расходнику, конфиг доставляется отдельно от сборки. Подход работает, и для подавляющего большинства соединений из России работает прямо сейчас.

Кроме одного класса сетей, в которых не работал.

Внутри этого класса оказались, в том числе, корпоративные подсети, гостевой Wi-Fi в некоторых аэропортах и часть регионального покрытия одного из операторов. Картина в логах одна и та же. Туннель поднимается, TCP-соединение на relay открывается, TLS-рукопожатие начинается, и через секунду sing-box на сервере пишет в журнал: REALITY: processed invalid connection. Сразу обрыв, нет ретраев которые что-то меняют.

Эта статья про то, что мы увидели в этих сетях, почему Reality в одиночку их не пробивает, и что мы поставили рядом, чтобы пробивал. Если читали предыдущую часть, продолжайте отсюда. Если не читали, важен один тезис: туннель у нас живёт внутри приложения, через sing-box, скомпилированный в нативный фреймворк, без системного VPN.

Оптимизация кода сервисов на Go под реальную нагрузку

Когда сервис на Go начинает «тормозить» под реальной нагрузкой, проблема почти всегда не в самом языке и даже не в алгоритмах. Чаще всего узкие места лежат на уровне работы с памятью, сериализации данных и неочевидных накладных расходов рантайма. Если сервис упирается в сеть, базу данных или внешние API — оптимизация кода даёт ограниченный эффект. Но в CPU-bound сценариях (парсинг JSON, агрегации, обработка данных) каждая лишняя аллокация и копирование начинают стоить дорого.

Ключевая особенность Go — автоматическое управление памятью через garbage collector. Это удобно, но под нагрузкой GC становится заметным фактором:

Всем привет! Меня зовут Миша, я разрабатываю платформу Яндекс Еды. В декабре я рассказывал, как Temporal без боли решает привычную проблему распределённой бизнес‑логики.

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

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

Привет. В прошлой статье мы в основном говорили про чтение — кэш в controller-runtime, informer’ы, Reflector, DeltaFIFO, почему r.Get в реконсайле не ходит в apiserver. Сегодня поговорим больше про запись.

Kubernetes по своей природе спроектирован так, что одним и тем же объектом могут управлять разные контроллеры — и это нормально. На один Deployment смотрят и deployment-controller (правит status), и HPA (правит spec.replicas), и admission-мутаторы (расставляют labels), и cert-manager (дописывает свои аннотации), и пользователь с kubectl apply. Каждый из них отвечает за свои поля и не лезет в чужие. И всё это работает.

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