Go *

Если что такое параллелизм более-менее все разработчики понимают, то объяснение асинхронности через аналогии с кассирами/поварами вредно, так как вводит в очень большое заблуждение.
В данной статье я разберу эту проблему на примерах Python и Go и попробую дать свою правильную аналогию.

Небольшая команда сделала мод-социальную-сеть для Minecraft, который объединяет в общий граф друзей игроков на любых поддерживаемых версиях клиента — от 1.7.10 до 1.21.1. Поддерживаются три популярных загрузчика модов и любые клиенты Minecraft, как лицензионные, так и офлайн. Серверная часть, веб-админка, обвязка и документация — всё своё.

Главное, что хотелось рассказать: дисциплина (не скорость) была решающим ресурсом, и категория продукта изменила правила игры настолько, что классическая формула «MVP на одной версии — потом расширяемся» оказалась контрпродуктивной.

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

Поэтому, в этой части начнем с самого простого – пакета atomic.

Концепции вокруг атомарных операций на уровне CPU я рассматривал здесь, поэтому советую почитать. Там мы даже пишем свой атомарный AND.

!Важно! Мы будем разбирать на примере src/internal/runtime/atomics, то есть внутреннего пакета, а не того, который представлен нам как пользователям(потому что в исходниках я не нашел реализации). Но по большей части операции одни и те же.

Go-сервис может идеально проходить функциональные тесты и уверенно отвечать на локальных прогонах, а потом внезапно развалиться под 1000 RPS: p99 улетает в секунды, в логах появляются таймауты, throughput проседает, а часть запросов вообще не получает HTTP-ответа.

В статье разберём, как подойти к такой деградации без гадания: прогнать нагрузку через vegeta и wrk2, правильно прочитать p50/p99 и status codes, проверить пул соединений к базе, настройки HTTP-клиента, горутины, GC, таймауты и быстро понять, где именно сервис начинает терять устойчивость.

Всё началось с доклада про AI-агентов. Заинтересовало настолько, что решил написать своего на Go. Было сложно, но получилось! Делюсь опытом: LangChainGo, инструменты, цепочки, MCP и интеграция с GigaChat.

Продолжение разбора реального кода с собеседования. В первой части разобрали 8 проблем concurrency и memory: race conditions, утечки горутин, проигнорированный mutex, TOCTOU. Это была первая половина из 21 бага в одном сервисе на 150 строк.

Сегодня — вторая часть. Тут нет страшных race conditions, но есть то, что выдаёт уровень разработчика на собесе: отношение к ошибкам, валидация, API design, graceful shutdown, observability. Эти баги не упадут “вдруг” в продакшене — они будут тихо пилить вам костыль за костылём, пока кто-то не сядет переписывать. Актуально для Go 1.26.

Напомню итог первой части: из 8 багов про concurrency на интервью нашёл 7, пропустил только TOCTOU race. В этой части из 13 багов пропустил два: package applike с func main() (то, что код не компилируется — банально не посмотрел на объявление пакета) и отсутствие slog (просто не зацепился за log.Println, а зря). Остальные 11 — поймал. Расскажу, какими паттернами в чтении кода я их вылавливал.

Когда я начал разбираться, чем в open source можно закрыть задачу ASOC / Vulnerability Management, выбор оказался довольно грустным. По сути единственный известный вариант это DefectDojo. Сам я его в production не тащил, но от коллег регулярно слышал одну и ту же боль: на больших объёмах findings он начинает захлёбываться, в UI быстро не хочется заходить, а аналогов с человеческим интерфейсом и БДУ ФСТЭК «из коробки» в open source я просто не нашёл. Так и появилась моя ASOC-платформа: Go + PostgreSQL + Redis Streams + React, развёртывание одной командой docker compose up, миллион findings без тормозов (почти), обогащение из 7 источников, формула приоритизации, которая учитывает не только CVSS, но ещё EPSS, CISA KEV и БДУ ФСТЭК. В статье расскажу про архитектурные решения, грабли и почему я выкинул ORM ещё до первой строчки SQL.

Это не статья про готовый коммерческий продукт и не пиар-релиз. Скорее разбор того, как и почему был спроектирован Red Lycoris, open source платформа для централизованного хранения, дедупликации, обогащения и приоритизации уязвимостей. Я делаю её один, и если кому-то она пригодится, буду только рад. Если найдёте, где я ошибся в архитектуре, буду рад вдвойне.

В первой части я показывал agent-memory-mcp v0.1.0: MCP-сервер на Go + SQLite, который даёт AI-агентам persistent memory, semantic search и RAG по документации проекта.

Во второй части разбираю, что изменилось после нескольких месяцев реального использования. Почему fallback между embedding-моделями оказался опаснее отказа, зачем понадобились local-only режим и reembed, почему одного semantic search мало для инженерной памяти, как появились session close, Claude Code hooks, canonical knowledge, stewardship, sedimentation и multi-hop recall.

Это не changelog, а разбор эволюции архитектуры: как простой memory tool вырос в memory backbone для инженерных агентов — слой, который не просто хранит заметки, а помогает поддерживать актуальное, проверенное и полезное знание проекта.

Загнивая от усталости, дописывая последнюю строчку последнего (или не очень) модуля системы, теша себя мыслями о скорой зарплате, каждый уважающий себя философ задаётся вопросом - а как контролировать в бою всё то, что мы написали¿¿

Глупец скажет - никак, мы же покрыли тестами.

Хитрец скажет - Grafana+Prometheus отдельными сервисами.

Психопат на крайней стадии выгорания скажет - поднимем отдельную админку и будем собирать метрики и инциденты без прометеуса, снимая снимки системы каждую минуту асинхронными воркерами под каждый компонент платформы, включая сервер, базу данных, объектное хранилище и кэш. На лету будем высчитывать дельты серверных метрик, а в завершение отрисуем всё это дело без графаны, силами Recharts и Святого Духа, упакуем в отдельную панель для технических администраторов и наконец - сделаем клиентский status-page платформы.

Yggdrasil - это экспериментальная оверлейная IPv6 mesh-сеть, уже неоднократно обсуждавшаяся на хабре. Под катом рассматриваем ее использование в качестве встраиваемой библиотеки в вашем go приложении.

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

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

Проблема обычно не в том, что матан бесполезен. Проблема в другом: его часто преподают как отдельный мир формальных конструкций, а разработчику нужен другой взгляд, более инженерный. Не “докажите теорему по Коши”, а “объясните, как изменяется функция, почему вычисления могут быть нестабильны и как это связано с кодом”.

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

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

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

Мне был необходим фундамент для создания:

Многоканальных сенсоров для PRTG

Утилит для сбора данных с сетевого оборудования, таких как MAC/ARP таблицы, режим работы портов, их состояние, информация о POE, информация о CDP/LLDP соседях и многое другое.

Приемника SNMP Trap/Inform сообщений версии 3 (с поддержкой смешанных трапов, как версии 2c так и 3 и с различными параметрами шифрования и аутентификации, то есть например часть оборудования шлет Trap и использует пользователя SNMPuser и использует шифрование DES, а часть использует пользователя useram и использует шифрование AES-256).

Утилит управления портами, POE и прочими функциями оборудования

Много внимания было уделено обработке ошибок и производительности.

Были изучены и учтены проблемы SNMP агентов на некотором оборудовании, с которыми мы столкнулись при использовании как gosnmp так и net-snmp и прочих библиотек.

Это вводная статья и надеюсь не последняя.

Что регулярно ломается в реальных сервисах, когда надо совместить YAML, .env, переменные окружения и вложенный Config.

Kubernetes давно стал повсеместной платформой, а написать к нему собственный оператор сегодня — задача нескольких часов. Стандартный путь — kubebuilder на основе controller-runtime: scaffold проекта, типы, реконсайлер. В типовых сценариях этого вполне достаточно. Но как только нагрузка растёт или поведение оператора начинает расходиться с ожиданиями, всплывает целый класс edge-кейсов, причина которых — непонимание того, как controller-runtime устроен внутри. Если вы пишете контроллеры для Kubernetes, этот материал поможет собрать целостную mental model и заранее избежать дорогих сюрпризов в проде.

В этой статье разберём внутреннее устройство controller-runtime и на его примере увидим, какие архитектурные решения лежат в основе самого Kubernetes. Начнём с того, как контроллеры читают объекты из Kubernetes API.

Есть распространённое заблуждение, что r.Get() в Reconcile ходит прямо в kube-apiserver, List() каждый раз смотрит «живую» картину мира, а после Update() можно сразу перечитать объект и увидеть свежее состояние. На практике всё наоборот: controller-runtime живёт на локальной копии данных через LIST+WATCH. Благодаря этому чтение в реконсайле обходится почти бесплатно и не нагружает control plane даже при сотнях вызовов в секунду — но ценой этой модели становится то, что оператор может внезапно съедать гигабайты памяти, делать скрытые O(n)-сканы и регулярно упираться в stale reads.

Статья рассчитана на тех, кто уже писал операторы на Go с использованием controller-runtime, но хочет собрать целостную mental model, а не жить с набором частных наблюдений. Фокус будет на практических последствиях для production-кластеров: память, трафик, консистентность чтения и поведение реконсайла.

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

Через пару дней я взяла LSM-дерево, мемтейбл на B-дереве(что временно) и компакшн. Дальше были и атомарные батчи, fsync, все хотелось оптимизировать, добавить отказоустойчивости, сделать все более быстро, серьёзно и чтоб хоть где-то полезно.

Я расскажу из каких частей состоит мой движок, почему принимала те или иные решения, где у меня все было не так гладко, компромиссы, что до сих пор не работает и отложено в долгий ящик. Если вы когда-нибудь писали свой storage — очередь, кэш, или свое NoSQL хранилище — мой опыт поможет вам в принятии некоторых решений.

Привет, Хабр.

Сегодня познакомим вас с самой долгожданной новинкой апреля — книгой «Алгоритмы на языке Go», которую мы успели выпустить в продажу 30 числа.

С типом float рано или поздно сталкивается почти любой разработчик. Сначала все выглядит просто. Есть float32, есть float64, можно хранить дробные числа, делить, умножать, считать проценты, средние значения, коэффициенты и что угодно еще. Кажется, что это просто «числа с точкой». Но именно здесь у многих начинаются странные баги.

Почему 0.1 + 0.2 != 0.3? Почему после серии вычислений число внезапно становится 9.99999999997 вместо 10? Почему сравнение двух значений с float64 иногда работает, а иногда ломает логику? Почему в деньгах float почти всегда плохая идея? И почему даже корректная формула может давать нестабильный результат? Проблема не в Go. Проблема в том, что float устроен не так, как его часто себе представляют. Это не «точное дробное число», а приближенное представление вещественных чисел в памяти компьютера.

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

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

Уже больше полутора лет я пишу автотесты на Go. За это время мы прошли путь от «зачем вообще тестировать на Go?» до «почему мы не сделали это раньше?».

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

В Go легко написать код, который компилируется, но раздражает при чтении: слишком длинные receiver’ы, странные имена пакетов, лишние повторы в вызовах, хаотичный регистр и utils, который постепенно превращается в свалку. Для начинающего Go-разработчика соглашения по именованию могут выглядеть как набор мелких вкусовых правил, хотя на практике они влияют на навигацию по проекту, читаемость API и стоимость будущего рефакторинга.

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

Продолжение прошлой статьи про ошибки на Go-собесах. В тот раз — про лайв-кодинг. Теперь — про code review: когда дают готовый сервис на ~150 строк и говорят “найди что не так, у тебя 30 минут”.

Разберём по косточкам реальный код с собеседования — микросервис трекинга рекламных кликов. Багов набралось 21, поэтому делю на две части. Первая — про самое страшное: concurrency, гонки, утечки памяти и горутин. Это то, что роняет сервис в проде. Часть 2 — про API design, ошибки и graceful shutdown — выйдет следом. Актуально для Go 1.26.

Из 21 бага на собесе я нашёл 18. Три самых тонких пропустил — потом, дома, перечитал спокойно и выписал. В этой части про concurrency пропустил один — TOCTOU race в дедупликации. Остальные семь — поймал. Расскажу как искал и какими красными флагами зацепился.