Go *

В Go нет фикстур, и в интеграционных тестах это быстро превращается в копипаст. Разбираем, как вынести инфраструктуру из автотестов и управлять жизненным циклом ресурсов.

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

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

Напоминаю, что эта статья – часть большого цикла разбора языка программирования Golang End 2 End. Но если вы уверены, что понимаете природу многозадачности, многопоточности, проблемы оных, а также то, как выполняются инструкции и пришли разбираться в самых примитивных механизмах синхронизации, то велком

Instructions reordering

Обычно мы считаем, что CPU добросовестно выполняет свои инструкции последовательно. Ровно так, как мы ему сказали. Но это не всегда верно!

Допустим есть код

В какой-то момент у нас один платеж начал жить с тремя курсами валют: checkout показывал сумму из Redis, payment-service ходил в API, а ledger писал проводку по снапшоту из Postgres. Расхождения были 2-5 тенге, иногда до 180. Разбираю, как это дебажили, какие костыли ставили и где DDD реально помог, без красивых схем.

Пока все обсуждают очередные сливы баз и особенности модерации в популярных «безопасных» мессенджерах, решил попробовать пойти другим путем. В этой статье рассказываю, как я скрестил Flutter и Go через CGO, прикрутил libp2p для создания P2P-сети и реализовал честное E2EE шифрование (Double Ratchet для личек и MLS для групп). Никакой централизации, никаких единых точек отказа. Делюсь результатами эксперимента.

Прежде чем погружаться в архитектуру, давайте посмотрим на контекст, в котором всё это происходит.

По данным исследования McKinsey 2022 года, технический долг составляет до 40% всего технологического портфеля компаний. И это не просто цифра в отчёте. Согласно опросу 2024 года среди технических руководителей, у более чем 50% компаний технический долг занимает свыше четверти всего IT-бюджета, блокируя внедрение новых функций. (Источник: vFunction, 2025)

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

Теперь о Go. По данным Go Developer Survey 2024, главной проблемой команд, работающих с Go, названо поддержание единых стандартов кода — в том числе из-за разного уровня опыта участников и привнесения не-идиоматических паттернов из других языков. (Источник: go.dev/blog/survey2024-h2-results)

Это напрямую про нашу тему: люди приходят из Java, Python, C# и приносят с собой архитектурные привычки, которые в Go не работают. Clean Architecture и DDD — не исключение. Их часто реализуют "как в Java", а потом жалуются, что Go — многословный и неудобный язык.

Давайте разберёмся, как делать это правильно.

Как мы сюда попали?

Представьте: вы начинаете новый Go‑сервис. Читаете статьи, смотрите видео, решаете «делать по‑взрослому». Создаёте структуру:

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

В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?”

Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы)

В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник.

Один вопрос про pgx — и три инструмента которые легко перепутать. QueryTracer не замена декоратору, декоратор не устарел, а выбор драйвера — неожиданно важное решение для observability. Какую комбинацию драйвера и обёртки выбрать — зависит от того что вы хотите видеть. В статье взгляд на комбинации драйверов и оболочек для анализа запросов в PostgreSQL. Разбираем на реальном проекте — с кодом, ошибками и выводами.

Лучше один раз разобраться, чем каждый раз сомневаться в выборе.

Go-код никогда не исполняется напрямую.

Любая строка Go превращается в машинные инструкции, которые выполняет CPU.

В этой статье мы разберём:

1) Какие инструкции генерирует компилятор Go

2) Как выглядит Go assembler

3) И что на самом деле выполняет процессор

Думаю с обзором и общими положениями мы закончили, поэтому начнем с фундамента – что происходит в CPU когда мы запускаем наше Go-приложение. Конкретно в этой статье разберем основные инструкции, которые может выдать для нашего CPU компилятор Go, что они из себя представляют и как соотносятся с кодом Go. Сразу оговорюсь, что это НЕ гайд по Go Assembler, а разбор того, что из себя представляет Go End 2 End. Попытка докопаться до истины

Напомню, что сам CPU определяет:

Приветствую всех!

У меня было обилие мыслей на тему того, что можно сюда написать и решил разобраться в фундаменте мироустройства языков программирования. Копнуть в самую суть с разбором когда американских дедов(и их же репозиториев), которые вполне себе могли написать нечто и под знаменитым кукурузным XXX самогоном.

Решил я фундаментально разобрать то, как работает Golang, потому что в интернете(YT, Конфы и пр.), на мой взгляд, крайне много откровенно поверхностной и верхнеуровневой информации. Я, конечно, буду рад, если вы укорите меня в моих слабых навыках поиска и покажете мне, что реальность не такая, какой я её выдумал, но субъективно это так.

Разборы здесь будут скорее про то, что лежит в порождении сумрачного американского гения по ссылке github.com/golang/go с периодической синхронизацией с официальной документацией.

Моя главная цель – разобрать всё максимально исчерпывающе, насколько я это смогу.

Чтож, поехали!

Ах, да. В этом цикле не будет особо веселых рисуночков с гоферами, а скучные блок-схемы, диаграммы и вырезки из кода.

Структурная схема

Всем привет! Меня зовут Егор Ермаков, я бэкенд‑разработчик в группе разработки процессинга Техплатформы городских сервисов Яндекса.

Техплатформа — это инфраструктурная платформа для всех городских сервисов Яндекса: Такси, Еды, Лавки, Доставки, а также для различных шеринговых сервисов — каршеринга, зарядных станций, самокатов и других.

Один из ключевых сервисов нашей команды — ProcaaS (Processing as a Service). Он предназначен для асинхронного выполнения динамических сценариев. Подробнее о самом сервисе, его архитектуре и роли в сетке микросервисов Такси мы рассказывали в предыдущей статье. В этом материале я хочу поделиться опытом решения одной непростой и при этом очень интересной технической задачи, с которой мы столкнулись в рамках развития ProcaaS, а именно — рассказать, как мы написали свой транслятор кода.

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

Каждый, кто работал с бухгалтерией, CRM или просто заводил контрагента вручную, знает эту боль. Вам присылают карточку компании в PDF, договор в DOCX или просто текстовый файл с реквизитами. Задача: достать оттуда ИНН, КПП, расчётный счёт и БИК, чтобы не схлопотать штраф за неверные данные.

Можно нанимать стажёра, который будет перепечатывать это в Excel. А можно довериться машине.

Мы в нашей компании долгое время решали эту проблему для своих внутренних задач (интеграция с 1С и автоматизация документооборота), а в итоге обкатали решение и выпилили в отдельный публичный сервис. Сегодня расскажу, как наш API извлечения реквизитов работает под капотом, покажу примеры кода на 6 языках (включая 1С, куда без него) и честно расскажу о таймаутах и подводных камнях.

Я Шевкопляс Дмитрий, технический руководитель проекта Swapno — сервис для обмена автомобилями ключ-в-ключ, без дилеров. Механика — как в Tinder: свайпаешь чужие авто, если оба владельца лайкнули машины друг друга — Swap Match, начинается обмен. В этой статье расскажу, как мы спроектировали и написали бэкенд на Go за 3 месяца: от выбора архитектуры до matching engine, AI-модерации фото и observability в продакшене. С реальными ошибками, которые мы допустили, и тем, как их чинили.

Несколько недель назад я описал на Хабре идею «честного российского мессенджера» с открытым кодом и прозрачным compliance. Та статья была про «зачем». Эта — про «как получилось». Web-клиент и Android-приложение полностью переписаны и работают в production, серверная часть развёрнута и обслуживает реальные подключения. iOS пока не трогали. Ниже — разбор архитектуры, решения, которые мы приняли, грабли, на которые наступили, и открытый набор людей в проект.

Подключили к своему ИИ-агенту в VS Code пару десятков MCP-серверов и ужаснулись счетам за API? Знакомая история. В этой статье рассказываю, как я устал платить за замусоренный системный промпт и написали toolc - прокси-шлюз на Go. Он прозрачно сжимает хаос из баз данных, скриптов и OpenAPI-каталогов в один компактный слой. Показываю на реальных бенчмарках (GPT-5.4, Claude 4.6), как правильная маршрутизация снижает затраты на токены на 60% и спасает LLM от галлюцинаций.

Если ты тоже смотришь на Dart как на backend-альтернативу для Node.js, лучше пройти этот путь на чужих ошибках. Полные результаты benchmark'а — Go, Node.js, Dart, Bun, Deno, .NET — с методологией, конфигурацией и сырыми цифрами лежат на GitHub. Под катом — сама история. Не технический отчёт, а инженерская драма: как 2 недели ушли на перенос архитектуры, почему всё выглядело идеально на бумаге, и как гипотеза с "экономией памяти" разбилась о реалии raw benchmark. И ещё — почему AI-агент сделал всё правильно, и именно это оказалось проблемой.

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

Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс. В этой статье по мотивам моего доклада для Golang Conf я расскажу про Go Memory Model, понятным языком объясню отношение happens before, затрону формализм и разберу его на практических примерах.

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

Знаете, что происходит, когда вы ставите Telega, «альтернативный клиент Telegram от ВКонтакте»? Ваш Telegram ID тихо уезжает в инфраструктуру OK/VK Calls. Без уведомлений. Без галочки «я согласен». Просто раз, и вы в индексе. Навсегда.

Я решил проверить, сколько людей в моих чатах уже засветились. Руками долго. Через плагин exteraGram можно по одному профилю за раз. Хотелось масштаба. Так появился antitelega: Go userbot, который сканирует целый чат и выдаёт список «засвеченных» прямо в Saved Messages.

А потом мой аккаунт заморозили. Но обо всём по порядку :)

Python берут за скорость реализации. C++ - за производительность и контроль над памятью.

А Go? Go выбирают те, кто любит Go. Я один из них. Долгое время я использовал связку bufio.Scanner + ScanWords + strconv.Atoi. Но стоит в задаче смешать числа, строки или посимвольный ввод - начинаются “танцы с бубном”. В какой-то момент мне надоело, и я написал contestio. Решения оказались простыми. То чувство, когда: “Чёрт возьми! Почему мне это не пришло в голову раньше!?”

Технология eBPF — интересная штука. С её помощью можно без труда внедрять в ядро Linux фрагменты кода, которые затем компилируются в коды операций (опкоды), которые гарантированно не обрушат работу ядра. Набор допустимых инструкций ограничен, переходы назад не допускаются (поэтому не будет никаких неопределённых циклов). При этом вы не можете разыменовывать указатели, но вместо этого можете выполнять проверяемые операции считывания через указатели, которые потенциально могут оказаться неудачными, но при этом не спровоцируют паник на всю систему. eBPF в ядре Linux можно закреплять в тысячах хуков (точек перехвата), в качестве которых могут выступать u-пробы, k-пробы, точки трассировки и даже такие штуки как отказы страниц. У eBPF есть целый спектр захватывающих возможностей, которые при этом очень активно разрабатываются. Фичи, поддерживаемые в каждой конкретной версии ядра, перечислены в виде списка по этому адресу.

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

Но если сценарий становится нелинейным (появляются развилки, выбор пользователя ведёт на разные экраны) всё усложняется. С этим E2E-тесты ещё справляются: пишем несколько тестов, каждый под свой путь. Сложнее, но решаемо.

Мы столкнулись с этим при работе с платформой в Услугах Авито: пользователь заполняет форму заявки, переходя между экранами. Логика переходов между экранами зависела от категории услуги, типа экрана и выбранных опций. Сценариев стало попросту слишком много. Пришлось искать другой путь. 

Меня зовут Константин Горностаев, QA в Авито, в этой статье я расскажу о подходе, который позволил нам решить эту задачу и получил название «система фейков».