Go *

В игре Warcraft есть такая тварь — железный голем. Здоровенная кукла, слепленная из глины и металла, которую оживляют магическим словом. Тупой, но мощный исполнитель. Сказали бить — бьёт. Сказали охранять — стоит насмерть.

Я захотел такого же, но в коде.

Телом пусть будет Telegram-бот. А мозгом — нейросеть. Не просто очередной «чат с ИИ», а настоящий кодинг-агент. Чтобы кидаешь ему проект, а он: «Тут у тебя SQL-инъекция, тут гонка данных, тут ты импорт забыл, и вообще у тебя в зависимостях дыра». Идея казалась простой: берём aiogram, прикручиваем DeepSeek, пишем промпт «ты senior-разработчик, разбери этот код» — и готово.

Первая версия была готова за вечер.

Я кинул Голему свой проект. Он задумался на пару секунд и выдал:

Описание модели памяти Go начинается со слов «если вы читаете этот документ — вы излишне умный, остановитесь». Многие и правда остановились, но не автор этой статьи. 

Привет, Хабр! Я — Игорь Панасюк, и это вторая часть материала по мотивам моего выступления на GolangConf, где я рассказывал о модели памяти Go. В первой мы разобрались с  отношением happens before, формализмом, посмотрели практические примеры и многое другое. Сегодня поговорим о линеаризуемости исполнения, барьерах памяти (можно ли опустить абстракцию модели памяти), гарантии для программ с data race и использовании продвинутых техник.

Когда я впервые увидел новости про Swiss Table в Go, у меня была простая мысль: "Окей, звучит неплохо, но что это реально меняет для обычного разработчика?" Снаружи почти ничего. Мы всё так же пишем map[string]int, читаем, записываем, удаляем значения и обходим map через range. Но внутри рантайма map теперь устроена иначе, и это как раз тот случай, когда изменение под капотом может заметно повлиять на производительность без переписывания бизнес-логики.

Начиная с Go 1.24, встроенная map использует новую реализацию на базе Swiss Table. Это не сторонняя структура данных и не новый синтаксис языка, а замена внутреннего механизма хранения пар "ключ - значение". В релизных материалах команда Go прямо пишет, что новая map стала одной из причин снижения накладных расходов рантайма в среднем на 2-3% на наборе репрезентативных тестов. При этом они отдельно предупреждают: результат зависит от конкретного приложения.

Первые великие оптимизаторы появились уже на таком низком уровне, как железо. По факту, задача выжимки ресурсов в программировании есть на любом уровне. В этой статье мы разберем оптимизации на уровне CPU такие как NUMA, prefetch, TLB и alignment.

Статья получится немного неоднородной и больше про “высокие материи”, что в принципе намекает на то, что разбор “железной” составляющей скоро подойдет к концу!

Вводная

Как мы рассматривали некогда ранее обращение на RAM – это достаточно дорого. CPU пытается это “скрыть”, чтобы работа казалась куда более быстрой.

Одним из таких механизмов, естественно, является иерархия кэшей!

Но вот не возникало ли у вас вообще вопроса – “А почему память – это в принципе проблема? Почему дорого?”. Все очень просто – доступ к памяти медленный

Тактовая частота например моего ноута – 2,70 ГГц, то есть 2,7 миллиарда циклов/операций в секунду

Доступ к ОЗУ имеет задержку аж в 150–350 циклов! То есть за это время мы могли бы выполнить 200 операций. 

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

Prefetch

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

На всякий случай зафиксируем:

В 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, затрону формализм и разберу его на практических примерах.

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