Go *

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

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

Дальше о том, как довести идею до инженерного состояния. Почему форма сообщения об ошибке влияет на исход правки сильнее, чем формулировка промпта. Какие поломки Go пропускает молча и чем их ловить. Как за полчаса написать свой анализатор, превращающий договорённость команды в ошибку сборки. И чем закончились попытки закрыть тот же вопрос документом AGENTS.md. Всё обкатано на монорепозитории примерно на сто восемьдесят тысяч строк, где за последний квартал около половины дифов написал агент.

Я делаю сервис, который разворачивает проекты юзеров на их серверах.

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

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

Кому полезно: тем, чей сервис просит доступ к секретам своих пользователей (серверы, репозитории, токены), да и в общем всем кто как-то связан с этой темой.

Всё чаще встречаю такую схему: берём LLM, даём ей доступ к kubectl или k8s API, в system prompt или подключённом skill‑е пишем что‑то вроде «ты можешь только читать, ничего не удаляй и не изменяй», и считаем вопрос закрытым. Прошёл через это сам и в какой‑то момент понял, что это не граница безопасности, а вежливая просьба.

Это не гипотетический риск: вы наверняка помните, как в июле 2025 агент Replit удалил базу данных SaaStr, несмотря на прямой запрет что‑либо менять — не Kubernetes и не MCP, но паттерн тот же самый. Инструкция «ничего не трогай» была прямо в контексте, исполнять её было просто некому, кроме самой модели. Дать агенту доступ на запись к k8s‑кластеру — значит собрать ровно ту же конструкцию, которая уже стоила SaaStr их базы.

Я далеко не первый, кто освещает эту тему, и за последнее время появилось множество read‑only MCP‑серверов. Но удивляет, насколько часто в них «read‑only» понимают неправильно. Например, у MCP‑серверов для Kubernetes “read‑only” нередко реализован как переменная окружения, которая фильтрует ответ tools/list, а не отсутствие функции в реестре. Именно так был устроен mcp‑server‑kubernetes (20 тысяч скачиваний в неделю на npm): флаг ALLOW_ONLY_READONLY_TOOLS прятал mutating‑инструменты из списка, а tools/call всё равно принимал kubectl_delete напрямую, в обход фильтра.

Получилась CVE-2026-46519, CVSS 8.8 — тот же принцип, о котором эта статья, доведённый до реального эксплойта: спрятанная из списка функция — не то же самое, что несуществующая. Причём это не только у сообщества — Azure/mcp‑kubernetes, официальный MCP‑сервер Microsoft для Kubernetes, устроен точно так же: --access-level readonly|readwrite вместо отсутствия mutating‑инструментов в принципе.

Броский заголовок есть, а теперь к сути. Сие ошибка, стандартный привет от дефолтного модуля pion/webrtc в Go. Воспроизводится просто – читаем обычные мануалы по использованию pion, выкатываешь красивый WHEP-хендлер, открываешь пару (ладно, ладно, не пару, просто красивый оборот) вкладок с плеером в браузере, и сервер начинает захлебываться. Хендшейки виснут по секундам, ICE отваливается по таймауту, а в pprof половина флеймграфа забита crypto/elliptic.p256OrdSqr и аллокациям мап внутри движка. Сюрприз? Да никакого сюрприза, если более вдумчиво почитать большинство «туториалов» по WebRTC на Go. Мне кажется, что они впринципе написаны теми, кто никогда не тестировал свою реализацию под нагрузкой даже полсотни одновременных зрителей – максимум пару-тройку потоков и успокоились на этом. Так вот, там на каждый POST-запрос с SDP-оффером создают новый webrtc.NewAPI(), регистрируют дефолтные кодеки, дергают api.NewPeerConnection() и со спокойной душой отдают ответ. На локалхосте, с парой клиентов это летает и работает без проблем. А вот на проде – превращается в катастрофу. Проблема здесь не в самом WebRTC (и уж тем более библиотеке pion`a, она очень крутая) и не в Go. Проблема в том, что глобальную и дорогую «инфраструктуру» создают на каждый(!) запросом, вместо того чтобы просто ее переиспользовать.

И она потрясающая, но я несколько выбился из сил, поэтому, как говорится, простите за неровный почерк :) Напоминаю контекст: f4 — эксперимент по переписыванию Far на go, чтобы сразу и кроссплатформенно и асинхронно. И красиво.

С красоты и начнём. На днях во фреймворк консольных интерфейсов vtui, который пишется под f4, добавлена поддержка Auto layout. Можно делать диалоги как у Apple! А чтобы это смотрелось красиво, предусмотрены две стратегии хинтинга: байткод, по аналогии с тем, как это сделано для рендеринга шрифтов у TrueType, и эвристики, как у FreeType. Для этого потребовалось портировать на go быструю считалку cassowary (пользуйтесь! там и wasm есть), а потом изобрести дискретный cossowary специально под консоль — задаем стандарты интерфейсов, люблю такое! И заодно — новая, уже полностью своя цветовая тема, не пытающаяся повторять что-то из Far, Turbo Vision или Monokai.

MASQUE — туннель, неотличимый от обычного HTTPS-трафика к Cloudflare, постквантовый VLESS, AmneziaWG, дотянутый до эталона. Всё это теперь не только в телефоне, но и прямо на роутере: отдельный Wi-Fi, весь трафик которого уходит в туннель. Рассказываю, как мое ядро sing-box-lx до этого доросло

Привет, Хабр! Меня зовут Степан Пестерников, мы с командой делаем Алису и активно используем СУБД Яндекса. Недавно коллеги из YDB провели большой рефакторинг в YDB Go SDK, где по умолчанию теперь используется новый Query Service.

Я воспользовался этим рефакторингом, чтобы уменьшить количество сетевых запросов от SDK к YDB. Клиентские SDK устанавливают к распределённой СУБД Яндекса gRPC-подключения, поверх которых отправляются низкоуровневые команды. Какие-то из этих команд можно объединять: например, команду начала транзакции и выполнения первого запроса.

В статье я покажу фрагменты кода и расскажу, как мы делали улучшения, которые вошли в релизы v3.126.0 и v3.126.5 Go SDK. Фрагменты кода получились небольшие, и на их примере удобно показать, как этими оптимизациями пользоваться.

Объясню кэш через холодильник, а потом покажу, где эта аналогия ломается, и что с этим делают в проде.

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

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

Через несколько дней (говно)кода стало много — вменяемого сервиса не получилось.

Один BFS принимал map[string][]string. DFS жил на другом типе графа. В одной реализации направленность задавалась на уровне графа, в другой вытекала из того, как было записано ребро. Опции существовали, но их комбинации не образовывали понятной политики. Result types возвращали срезы и числа, однако я не мог внятно ответить, что именно они гарантируют.

Проблема была не в том, что LLM «не умеет BFS». Я попросил реализации раньше, чем сформулировал общий контракт данных. Генератор заполнил пустые места правдоподобными допущениями — которые, очевидно, не совпали в разных кусках кода.

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

Эта серия для тех, кто выучил синтаксис Go, написал первые go func() и хочет понять, что за ними стоит. Многопоточность знать не нужно: начнем с того, что такое поток. К концу первой части ты будешь понимать, почему поток операционной системы дорогой, что такое горутина физически и как Go пришел к схеме GMP.

В начале августа я сел делать игру для мессенджера MAX – обычный вордли, слово из пяти букв, шесть попыток. Мини-приложение на ванильном JS, сервер на Go, самый дешёвый VPS. По моим прикидкам – три вечера.

Первый вечер целиком ушёл на то, чтобы сервер вообще смог поговорить с API мессенджера. Не на игру, не на словарь – на TCP-соединение.

Дальше было ещё семь таких мест. Каждое выглядело как мой баг, каждое оказалось особенностью платформы, и ни одного из них нет в документации. Ниже – все восемь, с кодом и с тем, как именно я до них дошёл. Игра тут нужна только как повод: она набрала 107 игроков за пять дней, это скромно, и рассказывать я собираюсь не про неё.

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

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

Последнее время я почти не пишу код руками — значительную часть реализации берут на себя AI-агенты. Но работы меньше не стало: теперь нужно задавать ограничения, проверять архитектуру и понимать результат, не перечитывая тысячи сгенерированных строк. Я попробовал сделать архитектурный граф общей моделью для человека, агента и генератора кода. Из одного графа получил сервисы на Go, Python, C++ и Rust, а затем сравнил их с прямыми реализациями того же HTTP → gRPC сценария. Главный вопрос эксперимента: какова runtime-плата за систему, которую проще понимать, изменять и наблюдать?

Привет, Хабр! Я Захар Захаров, разработчик в команде LBaaS. Контроллеры (они же операторы) в Kubernetes — паттерн, который выглядит просто на схеме из документации и неожиданно обрастает деталями, когда садишься писать его руками: очередь, воркеры, кэш, индексы, манифесты, схема, веб-хуки.

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

Если кто то, когда-либо занимался видеопотоками поверх интернета, т.е использовал классический медиасервер работающий по принципу RTSP to HLS (или ему подобные протоколы) тогда он знает какие проблемы возникают. Для примера возьмем двух гигантов, Flussonic и Wowza. В документации Flussonic`a есть четкие аппаратные характеристики при которых ЦП начнет долбиться в сотку: 250 камер с битрейтом 2 Мбит/c, на Xeon E3-1230v5 3.4 GHz + 32 GB RAM. У Wowza же четких примеров нет, но если немного «экстраполировать», то у нее на том же железе около 350-400 камер с битрейтом 2 Мбит/c, загружают процессор на сотку. Давайте внесу оговорку: я понимаю, что указанное железо довольно старое. Но 80% малого и среднего бизнеса на +/- таком работают, я имею ввиду тех, кто не пользуется облачной инфраструктурой или не арендует железо в ДЦ. Так вот, казалось бы, ну такая вот нагрузка, что с ней поделать? Проблема в том, что в моменте эти потоки никто не смотрит. Условный «охранник» залипает в телефоне, пьет кофе – а сервак 24/7 продолжает нарезать сырые кадры в HLS-сегменты и писать архив, грея серверную. Банальное расходование ресурсов в пустую, когда они не нужны. А в наш век стоимости на железо – стоит беспокоиться о таких вещах.

Решение на поверхности, и многие о нем знают – режим On Demand (по запросам). Нет зрителей – тушим камеру.  Есть зритель – отдаем HLS-поток. Казалось бы, все идеально, вопрос решен, расходимся. Но тут вылезает главная проблема классического On Demand - как только зрителей нет, соответственно камера потушена, запись архива не ведется. Для любой системы безопасности – это новомодный «ред флаг».

У меня 12 лет опыта в Go. И я больше не имею права назвать себя программистом: мой код не пройдёт ту планку качества, которую я выставил для своих агентов. Хотя честнее так: они сами её выставили, я лишь ставил цели.

Заявление громкое, но у меня есть график. Красная пунктирная линия на нём: уровень моего лучшего рукописного кода. Синяя кривая: код, который пишут агенты. В апреле 2026 кривая ушла под красную линию и продолжает падать.

ИИ-агентам нужно ходить по настоящему вебу. Но настоящий веб враждебен к автоматизации: Playwright блокируют, headless-версия Chrome палится по отпечаткам, а стелс-плагины просто становятся частью отпечатка. Если вы когда-нибудь писали скраперы или инструменты для агентов, вы знаете, как это бывает - всё работает локально, а потом продакшен разваливается за Cloudflare-челленджем.

Несколько проектов пытались решить эту проблему со стороны браузера. Проект https://camoufox.com патчит Firefox на уровне C++, так что navigator.hardwareConcurrency, WebGL-рендереры, AudioContext, геометрия экрана и WebRTC подменяются ещё до того, как JavaScript их увидит. Браузер https://github.com/jo-inc/camofox-browser оборачивает этот движок в REST API, заточенный под агентов: снимки доступности вместо раздутого HTML, стабильные ссылки на элементы для кликов и изоляция сессий.

Остаётся только одна дыра: инструментарий вокруг этой экосистемы завязан на JavaScript/Python. Если вы живёте в Go - а весь стек Go-агентов, взорвавшийся за последние пару лет, весомый аргумент в его пользу - вам оставалось писать сырые вызовы curl.

Пакет https://github.com/yvv4git/go-juggler исправляет это. Это Go-клиент для протокола автоматизации Juggler (того самого, который патчит и расширяет Camoufox) под лицензией MIT. Он управляет Firefox/Camoufox из Go с единственной зависимостью и чистым, слоистым API.

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

Суть проекта:

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

Цели проекта:

Выкатили мы первый релиз в прод (100 камер), обрадовали клиентов, начали работать. Прошел где-то час, полетели алерты. Залезаю на сервак, смотрю htop – а там свободно 100 метров ОЗУ. Пу-пу-пу-пу. Нужно внести уточнение что боевой сервер имел 32 гига озу. Ожидаемое поведение было то что процессор отдыхает, сетевуха переваривает трафик, озу 250-300 МБ, диски нагружены не сильно. Так что, когда видишь такие цифры в htop, начинаешь винить себя и свои кривые руки, написавшие это "Г". Но все же решили пойти в Гугл, чатгпт и тому подобное. Благо, ответ нашелся быстро, и посыпать голову пеплом перестали.

Код оказался не вообще не причем, память сожрал сам Линукс. Если когда-нибудь вы писали тонны данных на диск, я думаю вы уже поняли в чем дело. Есть такой «невидимый враг» как страничный кэш (Page Cache). Вот именно он и был корнем этой проблемы.

Как работает страничный кеш и что с ним делать?

Когда ваша функция, которая должна писать данные на диск пишет данные, на самом деле она не пишет их на диск. Она пишет их в ОЗУ. Логика ядра Линукса проста и банальна, и она направленна на ускорение «отзывчивости» системы, всю суть можно объяснить так: «О, только что записали сотню гигабайт данных, наверное, скоро понадобится эти данные прочитать. Оставлю-ка я их в кеше, пользователь будет рад что так быстро смог их прочитать.» И так гигабайт за гигабайтом, пока в сервере не кончится физическая память.

Типичное решение проблемы – пишем скрипт, который раз в час делает echo 3 > /proc/sys/vm/drop_caches. Ну а кто-то просто забивает и позволяет системе убивать случайные процессы через OOM Killer. Но мы же пишем отказоустойчивую штуку. Нам такое не подходит. Задача объяснить ядру ОС, что наши fMP4 сегменты видеоархива — это write-only мусор на небольшое количество времени (т.к если клиент не хочет долго хранить записи, то архив чистится, а если хочет – мы отправляем архив после N времени хранения в S3, а локальную копию тоже чистим). Так что все должно работать по принципу – записал и забыл.

Почти любой бэкенд рано или поздно сталкивается с необходимостью отложенной обработки задач: отправить email после регистрации, пересчитать агрегаты, выполнить задачу по расписанию. Часто для этого подключают отдельную систему — RabbitMQ, Kafka, Redis-очереди. Но если ваши данные уже живут в YDB, нужные примитивы уже рядом: таблицы, changefeed, топики и координационные ноды.

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