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

Трассировка через eBPF снимает налог на ручное инструментирование, но требует ядра не ниже 5.8, несрезанной таблицы символов и знания устройства планировщика Go.

При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов в ядро ежесекундно и потолок расхода в 200–600 мс процессорного времени на ядро.

Медленный запрос это не одна проблема, а пять разных: лишняя работа, борьба за ресурсы, давление среды, деградация плана и патологические шаблоны вроде N+1.

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

Версия браузера, тип навигации, библиотека сбора данных и версия инструментирования входят в определение метрики: смешав их в одном графике, вы увидите изменение измерения вместо изменения продукта.

Слой первый наблюдаемости: собрать данные, не трогая код

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

Альтернатива, ставшая эксплуатационно пригодной за последние пару лет, — подключение зондов eBPF напрямую к символам рантайма и точкам входа библиотек HTTP и gRPC. Трассы восстанавливаются из событий ядра и пользовательского пространства, а файл бинарника на диске не меняется вовсе: правки идут только в памяти работающего процесса, точечно и обратимо.

Почему с Go это сложнее, чем с C

Зонд работает так: в заданное смещение работающего бинарника ставится инструкция прерывания, при попадании в неё ядро останавливает поток, выполняет свою программу и возобновляет исполнение. Для C и Rust это ложится на прологи функций почти без остатка. Go добавляет три осложнения.

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

Соглашение о вызовах. В Go 1.17 аргументы функций переехали со стека в регистры, причём сначала только на amd64; на arm64 и ppc64 это произошло версией позже. Программа зонда, написанная под прежнее соглашение и читающая контекст со смещения от указателя стека, на новых бинарниках прочитает мусор. Значит, трассировщику нужна либо логика зондов под каждую минорную версию языка, либо вычисление места по отладочной информации самого бинарника.

Встраивание функций. Компилятор Go агрессивно встраивает мелкие функции, и нужный символ может просто отсутствовать по ожидаемому адресу. Зонд, поставленный не туда, даёт пропущенные отрезки трассы или испорченные аргументы, причём молча.

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

Главная нерешённая проблема: передача контекста между сервисами

Если нельзя вписать заголовок в коде приложения, как передать идентификатор трассы дальше по цепочке вызовов? Есть три подхода, и практически применим один.

• Писать заголовок прямо в пакет на уровне сетевого интерфейса. Требует расширенных привилегий и работает только для нешифрованного HTTP/1.1: шифрование выполняется выше уровня сокета, и программа видит уже зашифрованные байты.
• Пропускать исходящие вызовы через локальный вспомогательный прокси, который держит соответствие идентификатора горутины и контекста трассы и вставляет заголовки перед пересылкой. Добавляется сетевой переход, зато шифрование не ломается.
• Править карту заголовков прямо в памяти процесса. Соответствующая функция ядра помечена как опасная и действительно способна повредить память: каждая её загрузка пишет предупреждение в журнал ядра, работа требует широкой привилегии CAP_SYS_ADMIN, а в режиме блокировки ядра она запрещена совсем.

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

Что ломается в продакшене

• Идентификаторы горутин переиспользуются. При высокой конкурентности номер может уйти на новую горутину раньше, чем потребитель разобрал события старой.
• Обновление бинарника сдвигает смещения символов. Зонды старого отображения ядро снимает само, и новый бинарник какое-то время работает без трассировки. Слежение за изменением файла сокращает разрыв до секунд, но не убирает его.
• Требования к ядру. Кольцевые буферы нужны ядру от 5.8, а переносимая компиляция зондов требует 5.4 с включённой отладочной информацией о типах. Матрицу ядер стоит проверить до внедрения, а не после.
• Срезанные бинарники. Сборка без таблицы символов и отладочной информации лишает трассировщик возможности сопоставить имена функций со смещениями. Компромисс: оставить хотя бы таблицу символов, заплатив примерно 10–15% размера бинарника.

Сколько это стоит в процессорном времени

Зонды не бесплатны: каждое срабатывание это программное прерывание с входом в ядро. При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов ежесекундно. Опубликованные замеры дают порядка 1–3 мкс на срабатывание на современном оборудовании, то есть верхняя оценка расхода составляет 200–600 мс процессорного времени в секунду на одно ядро.

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

Правильный вывод не «заменить инструментирование зондами», а «использовать оба». Зонды дают сплошное покрытие и базовое распределение задержек без усилий разработчиков, включая сторонние бинарники, которые вы не можете изменить. Ручное инструментирование даёт смысловое наполнение: идентификатор пользователя, арендатора, флаг функциональности — то, чего из сырых байтов HTTP не синтезировать. Наиболее точные схемы наблюдаемости держат оба слоя, причём слой зондов работает проверкой на непротиворечивость для отрезков, которые приложение теряет под нагрузкой.

Слой второй: превратить трассы в решения

Собранная телеметрия сама по себе ничего не улучшает. Больше телеметрии означает больше объектов для разглядывания, а не больше понимания. Полезной она становится, когда из неё извлечены закономерности, на которые можно действовать.

«Медленный запрос» это пять разных диагнозов

Прежде чем что-то чинить, стоит понять, чем именно болен запрос. Разбор CNCF раскладывает медленные запросы к базе на пять непохожих причин:

• Лишняя работа. Обычно это полный перебор таблицы из-за отсутствующего или неприменимого индекса. Выборка по идентификатору клиента без индекса растёт с 20 мс на десяти тысячах строк до минут на десяти миллионах. Запрос не менялся, изменился объём данных.
• Борьба за ресурсы. Идеально оптимизированный запрос стоит в ожидании блокировок или свободного соединения. Запрос, проводящий 95% времени в ожидании блокировки, оптимизацией текста не лечится: ему нужна перекройка транзакций.
• Давление среды. Насыщение процессора, узкое место ввода-вывода и нехватка памяти замедляют любой запрос с любым планом: тот же текст запроса и тот же план на нагруженной машине отработает в разы дольше, чем на свободной, и оптимизировать тут нечего.
• Деградация плана. Данные и текст запроса те же, а план исполнения изменился. Устаревшая статистика после массовой загрузки заставляет планировщик выбрать заведомо плохую стратегию.
• Патологические шаблоны. Проблема N+1 выполняет сотню быстрых запросов по две миллисекунды последовательно, добавляя двести миллисекунд задержки на одно только выполнение, не считая сетевых издержек на каждый обмен с базой. Ни один запрос не является медленным, а шаблон катастрофичен и в журнал медленных запросов не попадает вовсе.

Чего не хватает встроенным инструментам базы

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

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

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

Слой третий: не принять смену измерения за изменение продукта

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

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

Общий тренд не объясняет вашу просадку

В июньском наборе данных о реальных пользователях Chrome, опубликованном в середине июля, доля источников с хорошей отрисовкой основного содержимого упала до 67,7%, с хорошей задержкой отклика на взаимодействие до 85,9%, а доля проходящих все три ключевых показателя до 55,3%. Исключением оказалась стабильность вёрстки, поднявшаяся до 81,4%.

Google объяснил движение сезонностью, сравнив его с прошлым годом. Контекст полезный, но он не является доказательством того, что у вас локально ничего не сломалось. Релиз, рекламная кампания, изменение формы согласия, сдвиг в составе устройств или новый сторонний скрипт способны совпасть с общеотраслевым движением.

Гарри Робертс формулирует критерий проверки прямо: если общая доля прошедших упала на 1,2 процентного пункта, а конкретный сайт просел на четыре, широкий тренд разницу не объяснил. Верно и обратное: если сайт почти идеально повторяет рынок по браузерам и устройствам, срочное расследование в коде потратит время всей команды впустую.

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

Изменение методики выглядит как изменение продукта

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

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

Компенсация это не исправление

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

Улучшение реальное, но документ по-прежнему перевёрстывается, если у картинки не заданы размеры или объявление меняет высоту. Браузер убирает одно видимое следствие, а причина остаётся на месте. Проверять после такого изменения стоит липкие шапки, ленты, интерфейс согласия и встроенные блоки, а чинить всё равно вёрстку, а не полагаться на маскировку.

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

Что забрать с собой

Три слоя решают три разные задачи, и провал на любом из них выглядит одинаково: дашборд есть, ответа нет. Без покрытия вы не видите части системы. Без перевода трасс в метрики видите всё и не понимаете ничего. Без дисциплины в чтении принимаете смену методики за регрессию.

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

Материалы разбора: устройство трассировки Go-сервисов через eBPF, перевод медленных запросов в метрики надёжности и разбор того, как метрики вводят в заблуждение.

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

Producer-Consumer — это схема, в которой производители и потребители работают независимо, обмениваясь данными через общий буфер конечной ёмкости. Ёмкость здесь работает главным механизмом защиты: именно она не даёт быстрым производителям завалить медленных потребителей.

Ручная координация через wait() и notifyAll() в блоках синхронизации даёт гонки и ложные пробуждения, а активное ожидание в цикле впустую жжёт процессор.

Готовая блокирующая очередь решает задачу целиком: при переполнении она сама останавливает производителя, обеспечивая обратное давление вместо переполнения памяти.

Горутины — это не потоки операционной системы, а лёгкие единицы, которые планировщик рантайма раскладывает по потокам, поэтому создавать их можно в количествах, немыслимых для системных потоков.

Три гарантии прогресса различаются строго: obstruction-free требует отсутствия помех, lock-free гарантирует прогресс системы в целом, wait-free — завершение каждой операции за ограниченное число шагов.

Отсутствие блокировок и использование атомарных операций сами по себе не дают wait-free: цикл повторных попыток без верхней границы — это lock-free, как бы его ни называли в описании библиотеки.

Уровень первый: блокирующая очередь Producer-Consumer

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

• Писать собственную логику блокировок через wait() и notifyAll() внутри синхронизированных блоков. Это приносит тонкие гонки и баги ложного пробуждения, когда поток просыпается без всякого уведомления.
• Крутить активное ожидание в бесконечном цикле поверх коллекции, не рассчитанной на многопоточность. Процессор загружен постоянной проверкой размера очереди, а корректности всё равно нет.
• Не предусмотреть обратного давления. Когда производители быстрее потребителей, буфер растёт, пока приложение не упрётся в нехватку памяти.

Правильная ментальная модель здесь кухонная: повара выкладывают блюда на раздачу фиксированной вместимости, официанты забирают их по готовности. Раздача заполнена — повар ждёт, и это нормальная работа системы, а не сбой.

В Java всё это уже реализовано в стандартной библиотеке:

Вся координация потоков спрятана внутри реализации очереди, и явных блокировок в коде не остаётся вовсе. Метод put останавливает производителя при переполнении, и это и есть обратное давление, ради которого затевалась ограниченная ёмкость.

Уровень второй: передача сообщений вместо общей памяти

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

Ключевое слово go перед вызовом запускает функцию конкурентно. Правда, у примера выше есть подвох: когда main завершается, программа выходит целиком, и горутина может не успеть отработать. Дожидаться её нужно явно:

Где здесь, собственно, очередь

Горутины сами по себе задачу производителя и потребителя не решают: WaitGroup лишь дожидается завершения, буфера и обратного давления в нём нет. Роль ограниченной очереди в Go играет буферизированный канал, и это прямой аналог кухонной раздачи из предыдущего раздела:

Поведение совпадает с блокирующей очередью один в один: отправка встаёт при переполнении, приём встаёт на пустом канале. Разница в акценте. В Java вы защищаете общий буфер, в Go передаёте значение из одной горутины в другую, и владение данными переходит вместе с ним.

Почему это не просто потоки с коротким именем

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

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

Уровень третий: очередь без блокировок

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

Три гарантии прогресса

Obstruction-free. Операция завершится, если в какой-то момент ей дадут поработать без помех со стороны других потоков. При непрерывных помехах прогресс не гарантирован вообще. Самая слабая из трёх гарантий.

Lock-free. Гарантирует прогресс системы в целом: даже если один поток застрял, какой-то другой обязательно завершит свою операцию. Отдельный поток при этом может голодать сколь угодно долго, но система не встаёт целиком.

Wait-free. Каждая операция завершается за ограниченное число шагов независимо от того, что делают остальные потоки. Ключевая формулировка здесь именно «ограниченное число шагов», а не «обычно быстро», «не использует блокировок» или «работает на атомарных операциях». Это формальное свойство, а не характеристика скорости.

Два неравенства, которые стоит запомнить:
Отсутствие блокировок не равно wait-free. Использование атомарных операций тоже не равно wait-free.

Почему мьютекса недостаточно

Очередь, обёрнутая в мьютекс, — это совершенно корректный многопоточный код на Rust. Но wait-free она не является: поток, захвативший блокировку, может быть снят с процессора планировщиком, и все остальные будут ждать его возвращения неограниченно долго. Для большинства задач это приемлемо, для систем с жёсткими требованиями по задержке уже нет.

Атомарность и упорядочивание — разные вещи

Процессор гарантирует, что атомарная операция неделима. Этого мало: нужно ещё, чтобы потребитель увидел записи, сделанные производителем до публикации флага. За это отвечает модель упорядочивания памяти.

Пара «освобождение и захват» создаёт отношение синхронизации: если потребитель увидел освобождающую запись, он гарантированно видит и все предшествовавшие ей записи. Это одна из центральных идей программирования без блокировок, и именно её упускают, заменяя мьютекс на атомарную операцию без всего остального.

Кольцевой буфер и номера последовательности

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

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

Тип UnsafeCell здесь означает ровно то, что написано на упаковке: обращаться к значению можно только из блока unsafe, компилятор проверку прекращает, и инвариант «в конкретный момент со слотом работает один поток» держится на номере последовательности, а не на системе типов.

Тип MaybeUninit здесь не для красоты: при ёмкости в 1024 элемента нужны 1024 места под значения, а не 1024 сконструированных объекта. Производитель получает уникальную позицию одним атомарным инкрементом, и никакого соревнования за неё не возникает:

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

Где заканчивается честность в названиях

Неприятная правда, которую стоит знать до выбора библиотеки: многое из того, что продаётся как wait-free очередь, на деле является lock-free. Причина в устройстве ядра алгоритма:

Операция обычно завершается быстро, но верхней границы на число неудачных попыток здесь нет, а именно она и определяет wait-free. И да, ровно такой цикл вы только что видели в нашей собственной очереди: строго говоря, на этом шаге она тоже lock-free, а не wait-free, и автор исходного разбора это прямо оговаривает. Строгая реализация требует ограниченной стратегии резервирования или механизма помощи: когда поток B встречает незавершённую операцию потока A, он не ждёт возвращения A, а доводит его операцию до конца сам. Так прогресс перестаёт зависеть от того, что планировщик сделал с конкретным потоком.

Какой уровень выбрать

Правило простое и почти всегда работает от обратного.

• Блокирующая очередь из стандартной библиотеки закрывает подавляющее большинство задач. Начинайте с неё и не пишите координацию потоков вручную.
• Модель с передачей сообщений выигрывает, когда конкурентных задач много, а связи между ними хочется описать явно, а не через набор общих структур под блокировками.
• Алгоритмы без блокировок берутся, когда есть измеренное требование к задержке, которое блокировка нарушает: не «хочется быстрее», а конкретная цифра в бюджете. И в продакшене их берут готовыми из библиотек вроде crossbeam, а разбирают по косточкам ради понимания механики.

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

Что забрать с собой

Задача Producer-Consumer решается на трёх уровнях, и уровень выбирается требованиями, а не вкусом. Ограниченный буфер с обратным давлением закрывает большинство случаев. Передача сообщений упрощает структуру, когда конкурентных задач становится много. Алгоритмы без блокировок нужны там, где блокировка нарушает измеренный бюджет задержки, и тогда важно понимать, какую именно гарантию вы покупаете.

Материалы разбора: задача о ресторанной кухне на Java, введение в горутины и модель конкурентности Go и построение wait-free очереди на Rust.

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

Под угрозой сервисы, которые открывают недоверенные файлы через Excelize: импорт таблиц, конвертеры и обработчики отчётов. Ограничение размера загрузки само по себе не устраняет проблему, поскольку приведённый исследователем файл занимает всего 3 072 байта. До исправления отчёт предлагает отсеивать неподдерживаемые зашифрованные контейнеры или изолировать обработку по времени.

• Причина: если первые восемь байт файла совпадают с сигнатурой OLE, Excelize идёт по ветке расшифровки независимо от того, задан ли пароль.
• Функция convertPasswdToKey выполняет spinCount итераций хеширования до проверки верификатора, а spinCount берётся из XML-потока EncryptionInfo без ограничений.
• Стоимость линейная, около 0,6 микросекунды на итерацию: 1e8 даёт около минуты, 1e9 около десяти минут; память при этом держится на 24 МБ.
• На пути нет context.Context, поэтому вызывающий код не может отменить операцию; после ответа HTTP-обработчика по таймауту горутина продолжит вычисление.
• Excel и LibreOffice обычно записывают spinCount 100 000; в отчёте такой вызов занимает 61 миллисекунду. Автор предлагает ограничить счётчик при разборе файла. Сообщил исследователь arpitjain099; уведомление опубликовано 6 сентября, идентификатора CVE и патча пока нет.

Как файл на три килобайта занимает библиотеку на минуту

Зашифрованные паролем книги Excel хранятся в OLE-контейнере, внутри которого лежит поток EncryptionInfo с параметрами шифрования и сам зашифрованный пакет. Excelize определяет такой файл по первым восьми байтам: функция openReaderAt ветвится только по заголовку и не смотрит, передал ли вызывающий код пароль в опциях. Дальше agileDecrypt вызывает convertPasswdToKey, где ключ выводится из пароля повторным хешированием; число повторов задаёт поле spinCount, и проверка хеша-верификатора идёт уже после этого цикла.

Само поле spinCount в коде объявлено как обычный int и заполняется голым xml.Unmarshal из потока файла. Никакой верхней границы нет, поэтому атакующий сам выбирает, сколько времени займёт вызов. Автор отчёта проверил это на выпущенных версиях с proxy.golang.org без директив replace:

Цикл появился вместе с файлом crypt.go в версии 2.3.1 и с тех пор не менялся. Память во время атаки остаётся плоской, около 24 МБ, поэтому её нельзя отловить ни лимитом памяти, ни OOM-киллером: процесс просто занимает ядро на выбранное атакующим время. Автор отмечает, что уязвимость касается только доступности и не угрожает программам, которые открывают файлы, созданные их же оператором.

Чем защититься, пока нет патча

Самый простой фильтр стоит на границе: если сервис не поддерживает зашифрованные книги, отбрасывайте файлы, которые начинаются с OLE-сигнатуры D0 CF 11 E0 A1 B1 1A E1, до вызова Excelize. Обычный XLSX это ZIP-архив и начинается с 50 4B 03 04. Такая проверка занимает одну строку и полностью закрывает вектор для сервисов без паролей.

Проверьте используемую версию Excelize в зависимостях проекта. В сохранённом advisory уязвимыми названы версии с 2.3.1 по 2.11.0 включительно, поле исправленных версий пусто. Следить за появлением патча следует по тому же advisory и релизам проекта; отсутствие предупреждения отдельного сканера само по себе не подтверждает безопасность зависимости.

Если зашифрованные файлы нужны, разбор стоит вынести в отдельный процесс или воркер с жёстким лимитом времени: context.Context на этом пути Excelize не поддерживается; остановить горутину снаружи невозможно. Полезно также разобрать EncryptionInfo самостоятельно и отклонить файлы, где spinCount больше, скажем, миллиона: Excel и LibreOffice обычно используют 100 000. Автор отчёта предлагает мейнтейнерам такой потолок на этапе парсинга.

Таймаут должен ограничивать именно вычисление. Возврат ошибки клиенту по истечении времени ожидания не останавливает цикл в уже запущенной горутине: в описанном пути нет механизма отмены. Изоляция в отдельном процессе позволяет завершить обработчик целиком, если он вышел за лимит. Это временное ограничение последствий; проверка недоверенного счётчика внутри библиотеки остаётся предлагаемым исправлением причины.

Почему это типовой класс ошибок для парсеров

Схема одна и та же: формат позволяет файлу самому объявить, сколько работы предстоит парсеру, а парсер верит. Вышло исправление libheif 1.23.4, где файл с неограниченным числом элементов давал квадратичное время разбора и полтора гигабайта памяти. У Excelize ситуация проще: нет ни рекурсии, ни аллокаций, только счётчик из недоверенного XML. Следить за исправлением стоит в репозитории проекта: в advisory должна появиться исправленная версия, после чего можно будет обновить зависимость и проверить импорт. О диагностике горутин в работающем сервисе рассказывает новый профиль в Go 1.27, а о девяти уязвимостях в curl того же класса мы писали на прошлой неделе.

Источники: GHSA-jrfj-fhj2-jjvm: Unbounded spinCount in agile decryption burns CPU during OpenFile, Репозиторий qax-os/excelize

Изображение на обложке: Excelize, логотип проекта

Для тех, кто держит Go-сервисы в проде, это закрывает старую дыру в инструментах. Обычный goroutine-профиль показывает, сколько горутин сейчас заблокировано, но не отличает штатное ожидание от горутины, которая уже никогда не проснётся. Раньше такие утечки искали руками по стекам или ловили в тестах пакетом goleak; сам релиз Go 1.27 вышел 19 августа, а разбор механизма команда опубликовала только сейчас.

• Профиль goroutineleak входит в Go 1.27 и доступен через runtime/pprof и net/http/pprof (/debug/pprof/goroutineleak).
• Ловит блокировки на отправке и приёме в канал, блокирующем select, Mutex, RWMutex, WaitGroup и Cond.
• Не считает утечкой ожидание файлового и сетевого ввода-вывода, системных вызовов и самодельных спинлоков.
• По словам команды Go, метод точный и почти не даёт ложных срабатываний; накладные расходы на память названы пренебрежимо малыми, худший случай для одного цикла GC оценён как O(n²).
• В примере из блога профиль нашёл 116 зависших горутин на одной строке с отправкой в небуферизованный канал.

Что такое утечка горутины и почему её было трудно найти

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

До Go 1.27 инструментов было три, и ни один не решал задачу для продакшена. goleak проверяет, не остались ли горутины после конкретного теста. Пакет synctest, появившийся в стандартной библиотеке Go 1.25, помогает тестировать конкурентный код с виртуальным временем. Обычный goroutine-профиль показывает заблокированные горутины, но не доказывает, что они не проснутся: всплеск нагрузки выглядит в нём так же, как утечка.

Как профиль отличает утечку от штатной блокировки

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

Команда Go утверждает, что механизм точный и «почти не даёт ложных срабатываний» (перевод редакции). Есть патологический случай: цепочка горутин, где каждая ждёт примитив, доступный только следующей. Для такой «гирлянды» проверка в худшем случае занимает O(n²) шагов за один цикл GC, поэтому в блоге советуют не включать сбор профиля постоянно, а снимать его периодически, например раз в четыре часа. Память на учёт горутин авторы называют пренебрежимо малой, а GC при этом продолжает работать параллельно с пользовательским кодом.

Разработка выросла из совместного исследования Орхусского университета, Университета Вашингтона в Сент-Луисе и Uber; академическую версию представили на конференции ASPLOS 2025.

Что видно в профиле на живом примере

В блоге разобран сервис, который раз в секунду запускает обработку десяти элементов и на пятом получает ошибку. Функция делает ранний return, оставшиеся воркеры зависают на отправке в канал. Программа подключает net/http/pprof и слушает localhost:6060; профиль снимают обычным способом:

Через несколько минут работы pprof показывает Total: 116 заблокированных горутин, и все они стоят на одной операции: отправке в канал ch. Исправление для примера тривиальное: сделать канал буферизованным на число воркеров, make(chan result, len(ws)), тогда воркеры допишут результаты и завершатся, даже если читатель ушёл.

Что профиль не ловит

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

Кому новый профиль ничего не даст: сервисам, где горутины блокируются в основном на сети, а не на каналах, и проектам, которые ещё не перешли на Go 1.27. Профиль работает только в рантайме этой версии; для старых сборок остаются goleak и ручной разбор стеков.

Как включить у себя

1. Обновить тулчейн до Go 1.27 (релиз от 19 августа 2026 года, заметки к выпуску) и пересобрать сервис.
2. Если net/http/pprof уже подключён, новый обработчик появится автоматически по пути /debug/pprof/goroutineleak; отдельной настройки не нужно.
3. Снимать профиль периодически, а не постоянно: команда Go предлагает интервал вроде четырёх часов из-за квадратичного худшего случая.
4. Смотреть в первую очередь на места с ранним return при ошибках, таймауты без select с контекстом и воркер-циклы, у которых читатель может уйти раньше писателей.

Схемы GC и полный пример кода лежат в посте команды Go. Из соседних новостей по инфраструктуре Go-сервисов на сайте есть разбор Kubernetes 1.37 и заметка о tailcat от Tailscale, написанном на Go.

Источники: Go Blog: Goroutine leak profiles, Go 1.27 Release Notes, Go Blog: Go 1.27 is released

Изображение на обложке: Go Authors, логотип Go

На практике это netcat для интернета: на одной машине запускаете tailcat в режиме ожидания и получаете одноразовый адрес-токен, на другой вызываете tailcat с этим адресом, и между ними появляется шифрованный двунаправленный канал. Сверху можно пустить SSH, передачу файлов или проброс порта. Для разового доступа к машине за NAT это заменяет и промежуточный сервер, и регистрацию в чужом сервисе.

• tailcat — CLI и Go-пакет github.com/tailscale/tailcat под лицензией BSD-3-Clause.
• Использует WireGuard, NAT traversal и DERP-релеи Tailscale, но не control plane: аккаунты, вход и tailnet не нужны; IP-адреса внутри туннеля есть, но пользователю их знать не требуется.
• Адрес машины — её публичный ключ с информацией о DERP-сервере для первого контакта, закодированный в строку с префиксом tc.
• Сценарии: SSH на машину за NAT, передача файлов, временный доступ; есть экспериментальная браузерная демонстрация на WebAssembly.
• Прототип под названием derpcat написан в сентябре 2023 года; обещаний стабильности API и CLI у проекта нет.

Как соединение работает без сервера-посредника

В обычном Tailscale центральный сервер (control plane) раздаёт машинам ключи друг друга и координаты, по которым их искать. В tailcat этого посредника нет: всё, что нужно для соединения, упаковано в сам адрес. По описанию в блоге, это публичный ключ WireGuard плюс сведения о том, через какой DERP-релей к машине можно достучаться, если прямой путь через NAT не найдётся; строка начинается с tc и кодирует эти данные в base64. Получатель адреса знает и кому доверять, и где искать.

No accounts, login flow, tailnets, or IP addresses.

Дальше работает тот же механизм, что и в Tailscale: машины пытаются пробить NAT и соединиться напрямую, а если не выходит, трафик идёт через DERP-релей, зашифрованный концами так, что релей содержимого не видит. Релеи Tailscale публичные, и их можно заменить своим. Ни root, ни TUN-интерфейс, ни права администратора не нужны: tailcat работает в пространстве пользователя как обычная программа.

Чем это отличается от ngrok, SSH-туннелей и самого Tailscale

От ngrok и подобных сервисов tailcat отличается тем, что не выставляет ничего в публичный интернет: соединение получит только тот, у кого есть адрес, а адрес — это ключ. От SSH-прыжков через промежуточный сервер — тем, что промежуточный сервер не нужен вообще: DERP лишь помогает найти друг друга и при необходимости ретранслирует уже зашифрованные байты. От Tailscale — отсутствием всей управляющей части: нет списка устройств, ACL, MagicDNS, нет и постоянной сети, каждое соединение живёт само по себе.

Отсюда и границы применимости. tailcat хорош для разового доступа: подключиться к ноутбуку коллеги, забрать большой файл с домашней машины из офиса, дать подрядчику временный вход на стенд. Для постоянной сети между десятками серверов с правами доступа он не замена Tailscale или WireGuard-конфигу, и авторы этого не обещают: README прямо предупреждает, что инструмент бесплатный, но стабильность API и CLI не гарантируется.

Как попробовать

• Установка при наличии Go: go install github.com/tailscale/tailcat/cmd/tailcat@latest; готовые бинарники смотрите в релизах репозитория.
• На принимающей стороне запустите tailcat в режиме прослушивания и скопируйте выданный адрес; на второй машине передайте этот адрес как аргумент.
• Поверх канала поднимайте SSH или пробрасывайте порт; для передачи файлов подойдёт обычное перенаправление stdin и stdout, как с netcat.
• Для закрытого контура поднимите собственный DERP-сервер: код релея открыт в репозитории Tailscale.
• Браузерная демонстрация на WebAssembly лежит на GitHub Pages проекта и показывает, что канал можно открыть даже из вкладки.
• Публичные DERP-релеи даны без SLA, с ограничением частоты запросов и лишь в нескольких регионах; для рабочих сценариев поднимите свой релей.

Контекст

Первый прототип под именем derpcat Фицпатрик написал в сентябре 2023 года, публично проект показали после конференции TailscaleUp в августе 2026-го. Мотив компании понятен: чем больше людей знакомы с её сетевым стеком, тем проще им потом прийти за полноценным продуктом. Для разработчика это честная сделка: рабочий инструмент под BSD-лицензией без обязательств, но и без гарантий, что завтра его интерфейс не изменится.

Источники: tailcat: Tailscale without Tailscale (блог Tailscale), Репозиторий tailscale/tailcat

Изображение на обложке: Tailscale

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

Go остаётся стандартным выбором для большинства микросервисов: быстрая компиляция, простота найма, огромная экосистема.

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

Zig подходит для узких, критичных к производительности участков и для интеграции с существующим C-кодом, но экосистема пока незрелая.

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

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

Почему именно эти три языка

В 2026 году для нового backend-проекта по-прежнему можно взять Java, C#, Python или Node.js. Но если речь заходит о высоких нагрузках, низкой задержке и контроле над ресурсами, внимание смещается к трём игрокам.

• Rust — язык с владением и заимствованием, дающий безопасность памяти без сборщика мусора.
• Go — язык с простой моделью конкурентности, статической линковкой и минималистичной философией.
• Zig — язык в духе C, но с современной системой сборки, comptime и явным управлением памятью.

Все трое компилируются в нативный код, дают один бинарник на выходе и не требуют виртуальной машины. Именно это отличает их от Java, C# и Python на старте.

Rust: максимум производительности, максимум сложности

Сильные стороны

• Безопасность памяти на этапе компиляции — нет use-after-free, data races и большинства утечек.
• Нулевая стоимость абстракций: высокоуровневый код часто компилируется так же эффективно, как ручной C.
• Мощная модель конкурентности поверх tokio или async-std.
• Зрелая экосистема: axum, actix-web, serde, sqlx.

Слабые стороны

• Крутая кривая обучения: borrow checker требует перестройки мышления.
• Долгая компиляция: полная пересборка крупного проекта занимает десятки секунд и минуты.
• Меньше кадров на рынке, чем у Go или Java.
• Итерации медленнее: каждая ошибка компилятора — это время на переделку.

Когда выбирать Rust

Rust логичен, если вы строите инфраструктуру — прокси, базы данных, очереди, edge-сервисы — или если профилирование показывает, что горячий путь съедает CPU и память. Примеры из продакшена: Cloudflare использует Rust на edge, Discord переписал на Rust часть read-path сервисов.

Go: скорость разработки в масштабе

Сильные стороны

• Компиляция за секунды и один статический бинарник для деплоя.
• Встроенные горутины и каналы — простая, но мощная конкурентность.
• Отличная стандартная библиотека и быстрое тестирование через go test.
• Большая база инженеров и проверенные практики в крупных компаниях.

Слабые стороны

• Сборщик мусора может давать всплески задержек, хотя в последних версиях паузы сокращаются.
• Меньше контроля над расположением памяти и размером структур.
• Пиковая пропускная способность ниже, чем у Rust и Zig, на CPU-bound задачах.
• Система типов и обработка ошибок минималистичны — кому-то этого достаточно, кому-то не хватает.

Когда выбирать Go

Go — выбор по умолчанию для команд из 5–50 человек, которым нужно быстро запускать CRUD-сервисы, API-шлюзы и data pipeline. Uber, Google и Яндекс активно используют Go в микросервисах. Если главная метрика — time to market, а не последний процент производительности, Go обычно выигрывает.

Zig: новый игрок с C-душой

Сильные стороны

• Производительность уровня C с более современным синтаксисом и системой сборки.
• comptime — выполнение кода на этапе компиляции для генерации оптимизированных структур.
• Прямое взаимодействие с C без FFI-слоёв.
• Маленькие быстрые бинарники и явное управление памятью.

Слабые стороны

• Экосистема backend-фреймворков и библиотек пока существенно меньше, чем у Rust и Go.
• Сообщество и количество инженеров на рынке ограничены.
• Ручное управление памятью перекладывает ответственность на разработчика.
• Некоторые части языка и стандартной библиотеки всё ещё эволюционируют.

Когда выбирать Zig

Zig хорош, когда нужна C-производительность, но с более удобным инструментарием, или когда приходится интегрироваться с существующим C-кодом. Пример из продакшена: финансовая база данных TigerBeetle написана на Zig. Для универсального backend в 2026 году Zig ещё рано называть mainstream-выбором.

Сравнение в цифрах

Ниже — иллюстративные цифры из оригинального материала, полученные на AWS c7g.2xlarge (Graviton3). Относитесь к ним как к точке отсчёта, а не как к гарантии для вашего сервиса: в реальности большее значение имеют I/O, запросы к базе данных и сетевая задержка.

Бенчмарки:
HTTP throughput — Rust 892K req/s, Go 734K req/s, Zig 812K req/s.
JSON-сериализация — Rust 1,2M/s, Go 890K/s, Zig 1,1M/s.
Память на 10K соединений — Rust 45MB, Go 78MB, Zig 38MB.
Размер бинарника — Rust 8,2MB, Go 12,4MB, Zig 6,1MB.
Время компиляции с нуля — Rust 42s, Go 3,2s, Zig 18s.
P99 latency — Rust 2,1ms, Go 3,8ms, Zig 2,4ms.

Реальные истории миграции

Discord: Go → Rust

Discord переводил read-path сервисы с Go на Rust из-за пауз сборщика мусора, которые проявлялись в хвостовых задержках. По данным компании, throughput вырос в несколько раз, а tail latency снизилась. Ключевой вывод: мигрировать стоит только горячие пути, а не весь сервис целиком.

Uber: Python → Go

Uber мигрировал часть микросервисов с Python на Go, чтобы обойти ограничения GIL и упростить масштабирование. Переход занял годы, но зато проходил постепенно: Go-совместимость и простота языка позволяли быстро обучать команду.

TigerBeetle: C++ → Zig

TigerBeetle — финансовая база данных, ориентированная на корректность и производительность. Команда выбрала Zig, отказавшись от сложности C++ и сборщика мусора. comptime позволил генерировать специализированные структуры данных под задачу.

Гибридная архитектура

На практике редко выбирают один язык на весь проект. Гораздо чаще используют гибрид:

• API Gateway и CRUD — Go: быстро писать, просто деплоить, легко искать людей.
• Горячие пути — Rust: низкая задержка и контроль над памятью.
• Специализированные компоненты — Zig: парсинг бинарных форматов, криптография, интеграция с C.

Такая схема позволяет получить скорость разработки в большинстве сервисов и производительность там, где она действительно нужна. Главное — разделять систему по чётким границам и не превращать проект в зоопарк ради самого зоопарка.

Что выбрать в 2026 году

Выбор зависит от приоритетов команды и задачи:

• Нужна скорость разработки и лёгкий найм — Go.
• Нужна максимальная производительность и безопасность памяти — Rust.
• Нужна C-производительность с современной сборкой и интеграцией с legacy на C — Zig.
• Команда маленькая и сроки горят — начинайте с Go, профилируйте, мигрируйте горячие пути при необходимости.
• Строите базу данных, прокси или edge — Rust становится очень сильным кандидатом.

FAQ

Выводы

Rust, Go и Zig — не конкуренты в прямом смысле, а инструменты для разных условий. Go задаёт темп разработки, Rust отвечает за надёжность и производительность, Zig покрывает специализированные ниши. Лучшая стратегия для 2026 года — начать с Go, измерять, а затем точечно внедрять Rust или Zig там, где данные это оправдывают.

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

Источник: Pooya Golchian — Rust vs Go vs Zig: High-Performance Backend Services in 2026.

Написать оператор можно на Go с помощью operator-sdk: сгенерировать скелет проекта, определить CRD, реализовать Reconcile и задеплоить в кластер. В этой статье разберём паттерн Operator и соберём рабочий оператор, который создаёт Deployment и Service по декларативной спецификации, отслеживает дрейф конфигурации и мгновенно откатывает несанкционированные изменения.

Оператор Kubernetes — это пользовательский контроллер, который расширяет API кластера собственными ресурсами (CRD) и непрерывно приводит фактическое состояние к желаемому.

Шаблон Reconcile — Observe → Create → Correct → Report — лежит в основе любого оператора: контроллер наблюдает, создаёт недостающее, исправляет отклонения и сообщает статус.

С помощью operator-sdk и kubebuilder-меток можно сгенерировать скелет проекта, CRD и RBAC-манифесты, не писать boilerplate вручную.

Owner Reference связывает дочерние ресурсы с родительским кастомным ресурсом (CR): при удалении WebApp Kubernetes автоматически уберёт связанные Deployment и Service.

Обновление статуса через Status().Update() изолировано от основного ресурса и предотвращает бесконечные циклы реконсиляции.

Почему стандартных примитивов Kubernetes не хватает

Kubernetes предоставляет мощный набор базовых абстракций: Pod, Deployment, StatefulSet, Service, Ingress. Они отлично справляются с запуском контейнеров, балансировкой трафика и базовым масштабированием. Однако эти примитивы агностичны к бизнес-логике приложения.

Представьте, что вам нужно развернуть production-grade кластер PostgreSQL. Помимо самих подов с базой, потребуются: инициализация репликации, управление резервными копиями, обновление версий без простоя, автоматическое переключение при отказе мастера. Всё это — операционная экспертиза, которую DevOps-инженеры накапливают годами. Оператор превращает эту экспертизу в автоматизированный контроллер, который круглосуточно следит за ресурсом и принимает решения.

Сегодня операторы де-факто стали стандартом для управления сложными stateful-приложениями в Kubernetes: от баз данных и брокеров сообщений до сервисных mesh и CI/CD-систем. Концепция была сформулирована инженерами CoreOS ещё в 2016 году, а сейчас поддерживается Cloud Native Computing Foundation (CNCF) как ключевой паттерн платформенной инженерии.

Архитектура оператора: CRD, Reconciler и control loop

Любой оператор состоит из двух ключевых компонентов:

• Custom Resource Definition (CRD) — расширение API Kubernetes, которое определяет новый тип ресурса со своей схемой Spec (желаемое состояние) и Status (фактическое состояние).
• Контроллер (Reconciler) — программный цикл, который постоянно сравнивает Spec и Status, а затем выполняет действия для их сближения.

Контроллер не работает по принципу «выполнил шаги и вышел». Вместо этого он реализует control loop: каждую итерацию можно запускать снова и снова — результат не сломается, потому что код сравнивает «что есть» с «что нужно» и корректирует только расхождения. Это критически важно, потому что события в распределённой системе приходят асинхронно, а состояние объекта могло измениться за время обработки предыдущего события.

Создаём проект с operator-sdk

Вручную писать весь boilerplate контроллера — неэффективно. Инструмент operator-sdk (основанный на Kubebuilder) генерирует стандартную структуру проекта Go, включая точку входа main.go, Makefile с целями для сборки и тестирования, а также инфраструктуру для управления CRD.

Инициализируем проект и создаём API с контроллером:

Флаг --resource сгенерирует Go-структуры, описывающие схему пользовательского ресурса. Флаг --controller создаст шаблон reconciler'а — файла, в котором мы будем писать логику управления.

Определяем схему CRD

Откроем api/v1/webapp_types.go. Здесь мы описываем два структурных блока: WebAppSpec — то, что задаёт пользователь в YAML-манифесте, и WebAppStatus — то, что оператор сообщает о текущем состоянии.

Важнейшая часть — kubebuilder-маркеры над основной структурой:

Маркер +kubebuilder:subresource:status сообщает Kubernetes, что для этого ресурса нужен отдельный endpoint /status. Без него любое обновление статуса будет восприниматься API-сервером как изменение всего объекта, что вызовет каскадную реконсиляцию и может привести к бесконечному циклу.

Маркеры +kubebuilder:printcolumn настраивают вывод команды kubectl get webapps: вместо голого имени ресурса пользователь увидит фазу, желаемое и доступное количество реплик.

Reconciler: сердце оператора

Файл internal/controller/webapp_controller.go содержит функцию Reconcile — точку входа в control loop. Перед ней размещаются RBAC-маркеры, которые генерируют манифесты прав доступа при выполнении make manifests:

Без этих маркеров оператор не получит прав на чтение и запись стандартных ресурсов Deployment и Service, и при запуске в кластере упадёт с ошибкой доступа. Разберём функцию Reconcile по шагам.

Шаг 1. Получение актуального состояния

Reconciler получает не сам объект, а лишь его имя и пространство имён. Это архитектурное решение Kubernetes: между постановкой события в очередь и его обработкой объект мог измениться. Поэтому первое действие — всегда запросить свежую версию ресурса из API.

Здесь apierrors импортируется из пакета k8s.io/apimachinery/pkg/api/errors, а ctrl — из sigs.k8s.io/controller-runtime.

Шаг 2. Реконсиляция Deployment

Сначала проверяем, существует ли связанный Deployment. Если нет — создаём его через вспомогательную функцию deploymentForWebApp.

Вызов return ctrl.Result{Requeue: true}, nil ставит событие обратно в очередь: контроллер немедленно перезапустит Reconcile для того же объекта, чтобы продолжить с следующего шага. Это удобнее, чем ждать следующего внешнего события.

Вот как выглядит функция deploymentForWebApp:

Owner Reference — это механизм garbage collection в Kubernetes. Когда пользователь удаляет ресурс WebApp, кластер автоматически удалит все дочерние объекты, на которые ссылается поле ownerReferences. Без этой связи после удаления кастомного ресурса в кластере останутся «зомби»-поды и сервисы.

Шаг 3. Обнаружение дрейфа конфигурации

Если Deployment уже существует, мы не просто идём дальше — сравниваем желаемое и фактическое состояние. Это и есть то, что отличает оператор от одноразового скрипта.

Представьте, что кто-то из команды в обход оператора выполнил следующую команду или подменил образ на уязвимую версию. Оператор мгновенно фиксирует расхождение и принудительно возвращает ресурс к значениям, заданным в WebApp.Spec.

Шаг 4. Реконсиляция Service

С вычислительным слоем разобрались — теперь нужен сетевой доступ. Логика полностью идентична: проверяем наличие Service, создаём при отсутствии, устанавливаем Owner Reference. Для локального тестирования в Minikube используем тип NodePort.

Вспомогательная функция serviceForWebApp строит объект Service с нужными селекторами и портами:

Шаг 5. Обновление статуса

Последний шаг — сообщить пользователю текущее состояние приложения через status subresource. Здесь критически важно использовать именно r.Status().Update(), а не r.Update().

Разделение основного endpoint ресурса и subresource /status — фундаментальное свойство Kubernetes. Оно гарантирует, что обновление статуса не триггерит новое событие изменения ресурса и, соответственно, не запускает бесконечную реконсиляцию.

Тестирование: как проверить, что оператор работает

Для локального тестирования подойдёт Minikube. Запускаем оператор в одном терминале, а в другом — создаём кастомный ресурс.

Проверяем, что оператор создал инфраструктуру и отчитался о статусе:

Демонстрация: откат несанкционированных изменений

Главная ценность оператора — самовосстановление. Сымитируем вмешательство: масштабируем Deployment в обход кастомного ресурса.

Мгновенно в логах контроллера появляется сообщение:

Лог оператора:
INFO Drift detected! Updating Deployment {"DesiredReplicas": 3, "ActualReplicas": 10}

А через несколько секунд избыточные поды начинают завершаться:

В это время статус WebApp отражает промежуточное состояние Scaling, а после полного схождения — автоматически переключается обратно на Running.

Когда операторы необходимы, а когда избыточны

Не каждому приложению нужен собственный оператор. Для stateless-сервисов, которые достаточно описать парой манифестов Deployment + Service, оператор будет накладным расходом. Однако есть категории систем, где без оператора не обойтись:

• Базы данных — PostgreSQL, MySQL, MongoDB, etcd: репликация, бэкапы, обновления, failover.
• Брокеры сообщений — Kafka, RabbitMQ, NATS: управление партициями, топиками, кластерной топологией.
• Сетевые компоненты — Ingress-контроллеры, service mesh: динамическая маршрутизация и политики безопасности.
• CI/CD и GitOps — Tekton, Argo CD: оркестрация пайплайнов и синхронизация состояния кластера с репозиторием.

В российской инфраструктурной практике операторы активно используются в Managed Kubernetes от крупных облачных провайдеров. Например, в Яндекс Облаке операторы лежат в основе managed-сервисов баз данных, обеспечивая автоматизацию резервного копирования, мониторинга и масштабирования.

Выводы

Паттерн Operator — это не просто модное слово в экосистеме Kubernetes, а проверенный подход к автоматизации эксплуатации сложных приложений. Вместо того чтобы полагаться на runbook'и и ручные действия инженеров, оператор кодирует операционную экспертизу в программу, которая работает круглосуточно, не устаёт и не забывает проверить важный шаг.

В этой статье мы прошли полный путь: от генерации скелета проекта через operator-sdk до работающего контроллера, который создаёт инфраструктуру, отслеживает дрейф конфигурации и автоматически восстанавливает желаемое состояние. Ключевые навыки — понимание асинхронной природы control loop, правильное использование Owner Reference и изолированное обновление статуса — применимы далеко за рамками Kubernetes.

Оператор — это не магия, а дисциплина. Каждая итерация Reconcile — это честный вопрос: «Что должно быть?» против «Что есть сейчас?». Ответить на него правильно — значит построить надёжную систему.

Полный код проекта доступен в репозитории автора оригинального туториала: SandeshOjha06/k8-operator. Если вы планируете развиваться в направлении platform engineering или SRE, умение писать и отлаживать собственные контроллеры станет серьёзным конкурентным преимуществом.

Источники:

• Building a Kubernetes Operator from Scratch with Operator SDK — оригинальный туториал Сандеша Оджха.
• Kubernetes Operators — официальная документация Kubernetes.
• Operator SDK — фреймворк для разработки операторов.
• The Kubebuilder Book — руководство по построению Kubernetes API и контроллеров.

В IPv6 каждый сетевой интерфейс получает link-local адрес из диапазона fe80::/10 (первые 10 бит фиксированы, остальное — адрес интерфейса). Если у машины два интерфейса — например, Ethernet и Wi-Fi — оба будут в одном и том же префиксе. Вопрос: как операционная система понимает, к какому именно интерфейсу адресовать пакет? Ответ — зоны (scopes).

В IPv6 зона интерфейса записывается через %: fe80::4%eth0. Это нужно, чтобы различать link-local адреса на разных сетевых интерфейсах.

В URL зона попадает внутрь квадратных скобок: [fe80::4%eth0]:80. Но символ % в URL — это начало percent-encoding, поэтому парсер ломается.

Решение — экранировать % как %25: [fe80::4%25eth0]:80. Это поведение зафиксировано в RFC 6874.

Проблема затрагивает не только Go, но и nginx, Python requests и браузеры. Поддержка зон в HTTP-клиентах остаётся фрагментарной.

Как зоны работают в IPv6

Зона (или scope ID) — это механизм, позволяющий ядру отличать адреса из пересекающихся диапазонов. Для link-local адресов fe80::/10 он критичен: без него роутинговая таблица не поймёт, через какой интерфейс отправлять трафик.

Формат зоны зависит от ОС. В Linux это имя интерфейса — eth0, wlan0, ens192. В Windows — числовой идентификатор интерфейса. Полный адрес выглядит так:

Квадратные скобки отделяют хост от порта — иначе двоеточия IPv6-адреса спутаются с разделителем порта.

Конфликт зон и URL

Теперь вставим этот адрес в URL. На первый взгляд всё просто:

Но попробуем распарсить его в Go:

Получаем ошибку:

Что произошло? В URL любой символ, не входящий в разрешённый набор, должен быть percent-encoded. Пробел превращается в %20, кириллица — в последовательности вроде %D0%90. Парсер видит %e и пытается декодировать его как hex-последовательность. et — не валидный байт, поэтому URL отклоняется.

Почему Go падает и как это чинить

С точки зрения стандарта Go ведёт себя корректно. RFC 3986 определяет URL-грамматику, а RFC 6874 специально дополняет её для IPv6-зон: символ % перед zone ID должен быть сам закодирован как %25.

Правильный URL выглядит так:

Проверяем в Go:

Вывод:

Go корректно декодирует %25 обратно в % при извлечении хоста. То есть библиотека поддерживает RFC 6874, но требует от вызывающего кода заранее закодировать зону.

RFC 6874: это не баг, а фича

В RFC 6874 формально описан синтаксис IPv6-адресов с зонами в литералах URL. Ключевой фрагмент:

То есть зона записывается не как %eth0, а как %25eth0. Это выглядит ужасно с точки зрения пользовательского опыта, но таково решение стандартизации: совместимость с существующей URL-грамматикой важнее эргономики.

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

И действительно, та же проблема есть и в других инструментах:

• nginx — тикет #623, созданный более десяти лет назад; проблема отсутствия поддержки link-local адресов с зонами до сих пор актуальна.
• Python requests — issue #6808: даже при ручном кодировании % как %25 библиотека некорректно обрабатывает IPv6-зоны в URL, потому что urllib3 декодирует %25 обратно в %.
• Браузеры — draft Schinazi объясняет, почему зоны ломают концепцию origin, и рекомендует использовать mDNS вместо прямого указания link-local адресов в URI.

Что делать разработчику

Если ваше Go-приложение работает с локальными IPv6-адресами — например, подключается к сервисам в Docker-сети, IoT-устройствам или внутренним API через link-local — учитывайте следующее:

1. Перед передачей IPv6-адреса с зоной в url.Parse всегда экранируйте % как %25.
2. Используйте net.JoinHostPort для сборки host:port — он корректно оборачивает IPv6 в скобки, но не кодирует зону. Дополнительное кодирование остаётся на вас.
3. Если адрес приходит от пользователя, валидируйте его до парсинга: зона должна содержать только допустимые символы (имя интерфейса в Linux, числовой ID в Windows).
4. Тестируйте на реальных интерфейсах с разными зонами, чтобы убедиться, что кодирование работает корректно в вашей среде.

На заметку:
Если вы пишете HTTP-клиент для embedded-устройств или промышленных контроллеров, которые общаются через link-local IPv6, ручное кодирование зоны — не костыль, а необходимость. Большинство библиотек не делают этого автоматически.

FAQ

Выводы

IPv6-зоны — редкий, но живучий граничный случай. Если вы пишете сетевой код на Go, который должен работать в гетерогенных средах — Docker, Kubernetes, embedded-системы, промышленные сети — знайте, что fe80::1%eth0 в URL превращается в fe80::1%25eth0. Это не баг парсера, а требование стандарта RFC 6874.

Инкапсулируйте кодирование зоны во вспомогательную функцию и всегда прогоняйте IPv6-адреса через неё перед сборкой URL. Экономия пяти минут сейчас обернётся часом отладки в продакшене, когда сервис внезапно не сможет достучаться до соседнего контейнера по link-local.

Источники:
• Xe Iaso — IPv6 zones in Go URLs
• RFC 6874 — Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
• draft-schinazi-httpbis-link-local-uri-bcp-03 — IPv6 Link-Local URIs

Проект написан на Go — языке, с которым автор раньше почти не работал. Весь процесс разработки прошёл через GitHub Copilot CLI: вместо того чтобы разбираться в деталях синтаксиса незнакомого языка, можно было описать нужное поведение и получить работающий код.

GitHub Dungeons — расширение gh extension, которое генерирует рогалик из вашего репозитория прямо в терминале.

Процедурная генерация работает через Binary Space Partitioning (BSP), засеянный SHA последнего коммита — один и тот же код всегда даёт одно и то же подземелье.

Команда /delegate в Copilot CLI передаёт задачу облачному агенту, который работает асинхронно и открывает готовый PR.

«Опасный режим»: можно настроить pre-commit хук, который удалит все несохранённые изменения, если проиграть.

Установка одной командой: gh extension install leereilly/gh-dungeons.

Что такое GitHub Dungeons

GitHub Dungeons — это терминальная игра в жанре рогалик, где каждый уровень генерируется на основе вашей кодовой базы. Комнаты, коридоры и враги строятся из структуры репозитория и отрисовываются прямо в консоли. Навигация — стрелками, WASD или Vim-клавишами. Цель — найти скрытый выход, преодолев пять уровней с нарастающей сложностью.

Рогалики (roguelikes) ведут историю с игры Rogue 1980-х — терминальных приключений, где каждое прохождение генерировало новые подземелья, а смерть означала начало сначала (permadeath). GitHub Dungeons обращается к этой традиции, добавляя инженерный твист: ваш последний коммит задаёт seed генерации — один и тот же код всегда даёт одно и то же подземелье, но каждое изменение перестраивает его.

Как репозиторий превращается в подземелье

Генерация уровней построена на алгоритме Binary Space Partitioning (BSP) — классическом методе процедурной генерации карт в играх. В качестве seed используется SHA последнего коммита репозитория, что обеспечивает детерминированность: один коммит — одно подземелье. Изменился код — изменилась карта.

Процедурная генерация (или procgen) — это создание контента алгоритмически, а не вручную. Вместо того чтобы проектировать одно подземелье, вы проектируете систему, которая генерирует их бесконечно. Именно это даёт рогаликам высокую реиграбельность: каждое прохождение структурно отличается от предыдущего.

Как работает Binary Space Partitioning

BSP — это рекурсивное разбиение пространства на прямоугольные регионы. Алгоритм прост в объяснении, но даёт именно тот баланс между структурой и хаосом, который нужен рогаликам:

1. Начало. Весь уровень — один большой прямоугольник.
2. Разбиение. Пространство делится на два региона (горизонтально или вертикально). Каждый регион снова делится. И снова.
3. Остановка. Разбиение прекращается, когда регион становится слишком маленьким для комнаты.
4. Комнаты. Каждый конечный регион становится комнатой. Позиция и размер слегка рандомизируются — чтобы карта не выглядела как сетка.
5. Коридоры. Алгоритм обходит дерево разбиений в обратном порядке и соединяет соседние комнаты L-образными коридорами.
6. Результат. Карта выглядит спроектированной, хотя создана алгоритмически. Все комнаты достижимы, нет тупиков.

BSP решает две главные проблемы процедурной генерации: чистый рандом даёт хаотичные карты, регулярные сетки — предсказуемые. BSP находит баланс: структурированный хаос, где каждый забег выглядит по-разному, но остаётся проходимым.

Разработка с GitHub Copilot CLI

Ли Рейли написал GitHub Dungeons на Go — языке, которым он не пользовался регулярно. Copilot CLI позволил сосредоточиться на поведении игры, а не на синтаксисе: вместо того чтобы вспоминать, как работают горутины, можно было описать нужное поведение и получить работающий код.

Команда /delegate: асинхронный агент

Ключевым инструментом в разработке стала команда /delegate. В отличие от обычного автодополнения, /delegate передаёт задачу облачному агенту Copilot, который работает асинхронно. Разработчик описывает задачу на естественном языке, запускает делегирование и может заниматься чем-то другим. Когда агент завершает работу, он открывает pull request с результатами.

Например, команда /delegate с описанием задачи на естественном языке вернула готовую реализацию прогрессии сложности в виде PR. Автор просмотрел результат, подправил баланс и влил изменения. Тот же подход использовался для читкодов, системы туман войны и документации.

Работа с Copilot (особенно через /delegate) — это как иметь армию NPC, готовых делать всё, что я скажу.

Команда /yolo: живёшь только раз

Для проекта о рогалике команда /yolo оказалась особенно уместной: это алиас для /allow-all, который разрешает Copilot CLI выполнять все действия без дополнительных подтверждений. «You only live once» — именно это слоган permadeath-механики рогаликов. В разработке /yolo ускоряет итерации: не нужно подтверждать каждое действие агента.

Copilot также сгенерировал «dungeon scribe» — вспомогательного агента, который добавил документацию и ASCII-диаграммы, объясняющие генерацию подземелий. Это органично вписалось в стиль терминального рогалика.

Установка и игра

Для запуска нужен установленный GitHub Copilot CLI. Расширение устанавливается одной командой:

После установки запустите игру в директории любого репозитория:

Управление: стрелки, WASD или Vim-клавиши (hjkl). Цель — найти скрытую дверь и сбежать через пять уровней, сражаясь с врагами и собирая зелья здоровья. Автоатака, туман войны, счётчик убийств и уровней входят в комплект. Остальные возможности придётся обнаружить самостоятельно.

Опасная зона: pre-commit хук с ставками

Для тех, кто хочет испытать настоящий permadeath в духе рогаликов, автор предлагает привязать игру к git-коммитам. Pre-commit хук запускает GitHub Dungeons перед каждым коммитом: если проигрываете — все несохранённые изменения удаляются.

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

Выводы

GitHub Dungeons — эксперимент, который демонстрирует несколько интересных вещей одновременно. Во-первых, Copilot CLI меняет паттерн разработки: когда агент берёт на себя незнакомый синтаксис и рутину, разработчик остаётся в режиме дизайнера механик, а не кодировщика. Для этого рогалика это означало итерации по балансу, тайным кодам и пасхалкам вместо бесконечной отладки Go-специфики. Во-вторых, классические алгоритмы вроде BSP решают современные задачи: детерминированный seed из SHA коммита — это не случайность, а осмысленная связь между состоянием кода и состоянием игры. Каждый мердж меняет карту.

Попробовать GitHub Dungeons можно в любом репозитории: github.com/leereilly/gh-dungeons. Оригинальный разбор от автора — на GitHub Blog. Установите, запустите gh dungeons в своём репозитории — и посмотрите, каким подземельем стал ваш последний коммит.

• Wake-on-LAN — сетевой протокол для удалённого включения компьютера через Magic Packet.
• Magic Packet: 6 байт 0xFF + MAC-адрес, повторённый 16 раз.
• Пакет отправляется по UDP на широковещательный адрес 255.255.255.255, де-факто стандарт — порт 9.
• Ограничения: только в пределах одной сети или VLAN, только по Ethernet, нет подтверждения доставки.
• Реализуем собственный WOL-инструмент на Go с нуля.

Что такое Wake-on-LAN

Wake-on-LAN (WOL) — протокол канального уровня, который будит компьютер или сервер, когда сетевой интерфейс получает специальный Magic Packet. Сетевая карта с активированной функцией WOL постоянно прослушивает широковещательный трафик даже когда компьютер выключен, но подключён к сети. При обнаружении Magic Packet она посылает сигнал на BIOS, и система загружается.

Для работы WOL необходимо, во-первых, включить поддержку в BIOS или UEFI (обычно называется Wake-on-LAN или Power On by PCI-E); во-вторых, активировать её в операционной системе для нужного сетевого адаптера. На Linux это делается одной командой:

Здесь g — режим MagicPacket. Проверить текущее состояние — ethtool eth0 | grep Wake. На Windows нужную опцию ищите в «Свойства сетевого адаптера → Управление электропитанием → Разрешить этому устройству выводить компьютер из ждущего режима».

Как устроен Magic Packet

Magic Packet — бинарный фрейм с жёстко заданной структурой. Сначала идёт синхропоследовательность: 6 байт 0xFF. Эти байты сигнализируют сетевой карте о начале нового фрейма.

Сразу после синхропоследовательности — MAC-адрес целевой машины, повторённый 16 раз без пробелов и разделителей. Именно по нему сетевая карта понимает, что пакет адресован ей. В итоге Magic Packet занимает 102 байта: 6 байт синхропоследовательности плюс 6 байт MAC × 16 повторений.

Пример реального Magic Packet с MAC-адресом 12:34:56:78:9a:bc, захваченного в Wireshark:

Некоторые реализации WOL поддерживают опциональный пароль в конце пакета — для защиты от несанкционированного включения. Механизм SecureOn использует 6 байт, AMD-спецификация допускает 4 байта. Однако не каждый BIOS поддерживает эту функцию.

Как отправить Magic Packet

Magic Packet может быть передан поверх любого сетевого протокола — сетевой карте достаточно найти нужную последовательность байт в полученном фрейме. На практике пакет отправляют как UDP-датаграмму на широковещательный адрес.

Для IPv4 используется широковещательный адрес 255.255.255.255 — он охватывает всю локальную сеть или сегмент. IPv6 вместо broadcast использует multicast. Де-факто стандарт для порта назначения — 9 (Discard Protocol), реже используют 7 или 0.

Ограничения Wake-on-LAN

Прежде чем настраивать WOL в продакшне, важно понять его ограничения:

• Только одна сеть или VLAN. Magic Packet не маршрутизируется — получить его может лишь устройство в той же локальной сети или VLAN, что и отправитель. Для удалённого включения через интернет нужен промежуточный узел в этой сети: VPN, Raspberry Pi или роутер с поддержкой WOL.
• Нужен MAC-адрес. WOL работает на канальном уровне, поэтому нельзя разбудить компьютер, зная только его IP-адрес.
• Только проводной Ethernet. Большинство Wi-Fi-адаптеров не поддерживают WOL. Исключение — устройства с поддержкой стандарта WoWLAN (Wake on Wireless LAN), но на практике их мало, и настройка требует совместимого драйвера.
• Нет подтверждения доставки. UDP — протокол без установления соединения, поэтому после отправки Magic Packet невозможно узнать, получил ли его компьютер и включился ли он.
• Зависимость от BIOS. Некоторые материнские платы пробуждаются только из состояний S3 или S4, но не из полного выключения S5. Проверяйте документацию к платформе.

Реализация на Go

Напишем собственный WOL-инструмент на Go — одна из немногих задач, где стандартной библиотеки хватает полностью. Если хочется погрузиться в Go глубже, у нас есть обзор Golang-фреймворков 2026 года. Нам понадобятся две функции: CreateMagicPacket для формирования пакета и SendMagicPacket для его отправки.

CreateMagicPacket: формируем пакет

Функция принимает MAC-адрес строкой и возвращает готовый байтовый срез или ошибку. Первым делом проверяем валидность MAC-адреса с помощью регулярного выражения:

После валидации убираем разделители из MAC-адреса, затем повторяем его 16 раз:

Объединяем синхропоследовательность с повторённым MAC-адресом и декодируем hex-строку в байтовый срез:

SendMagicPacket: отправляем пакет

Функция принимает Magic Packet ([]byte), IP-адрес назначения и порт. Сначала проверяем валидность IP через стандартную функцию net.ParseIP — в отличие от regex, она корректно обрабатывает и IPv4, и IPv6:

Открываем UDP-соединение через net.Dial. WOL не требует установления соединения — UDP идеально подходит: быстро, без handshake. Ключевое слово defer гарантирует закрытие соединения по завершении функции:

Отправляем Magic Packet в сеть через conn.Write. Если функция возвращает nil — пакет ушёл в сеть. Получил ли его компьютер и включился ли — WOL не сообщает, это ограничение протокола:

Полный рабочий код обеих функций и готовую утилиту командной строки можно найти на GitHub: xaner4/Gowakeup. Типичный вызов после сборки — ./gowakeup -mac AA:BB:CC:DD:EE:FF.

Выводы

Wake-on-LAN — простой и элегантный протокол канального уровня. Всего 102 байта — и компьютер включается по сети без дополнительной инфраструктуры. Ограничения (только Ethernet, только локальная сеть, нет подтверждения) — следствие намеренной простоты протокола: он работает даже тогда, когда ОС не загружена. В отличие от устаревших сетевых стеков, которые ядро Linux постепенно отбрасывает, WOL остаётся в строю уже третье десятилетие.

Реализация на Go показывает, как стандартная библиотека net и базовые операции со строками позволяют собрать рабочий сетевой инструмент в нескольких десятках строк. Готовый проект: github.com/xaner4/Gowakeup. Исходная статья: blog.xaner.dev.

В Go для этого есть Bleve — файловая библиотека полнотекстового индексирования. Она умеет индексировать любые Go-структуры с разумными настройками по умолчанию, поддерживает встроенный язык запросов в стиле Google, работает с миллионами записей и не требует отдельного сервера.

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

Ключевые выводы

- Bleve — встраиваемый полнотекстовый движок для Go: не нужен отдельный сервер, достаточно одной зависимости
- Кастомные маппинги позволяют настроить анализатор, стемминг и стоп-слова для каждого поля отдельно
- IndexAlias объединяет несколько индексов (например, по языкам) в один виртуальный — с единым интерфейсом поиска
- Курсорная пагинация через SearchAfter / SearchBefore работает стабильно даже при обновлении индекса между запросами
- Scorch-настройки (воркеры, размер сегментов, порог мёржа) критичны для производительности под нагрузкой

Создаём простой индекс

Начнём с минимального примера. Два базовых действия — индексирование (сохранение документа для последующего поиска) и запрос (извлечение документов, отсортированных по релевантности).

Несколько важных деталей:

• bleve.New vs bleve.Open — New создаёт новый индекс по указанному пути, Open открывает существующий. Паттерн из примера (сначала New, при ошибке — Open) — идиоматический способ обработки первого и повторных запусков.
• NewIndexMapping() — возвращает маппинг по умолчанию: текстовые поля токенизируются, приводятся к нижнему регистру и фильтруются через список стоп-слов английского языка.
• Автоматическое обнаружение полей — Bleve использует рефлексию для анализа структуры. Все экспортируемые поля автоматически токенизируются и становятся доступными для поиска.
• Уникальные ID документов — строковый идентификатор, передаваемый в Index, используется для обновлений и удалений. Повторный вызов Index с тем же ID заменяет документ.
• SearchRequest.Fields — по умолчанию Bleve возвращает только ID и релевантность. Укажите имена нужных полей или []string{"*"}, чтобы получить все.
• hit.Score — каждый результат содержит числовой показатель релевантности на основе BM25. Чем выше — тем точнее совпадение.

Кастомные маппинги полей

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

Маппинги позволяют:

• Управлять токенизацией — разбивать текст на термы по пробелам, языковым правилам, edge n-граммам и другим стратегиям
• Фильтровать входные данные — приводить к нижнему регистру, удалять HTML, применять стоп-слова и стемминг (чтобы «running» и «runs» находились по запросу «run»)
• Исключать поля из индекса — пропускать чувствительные или нерелевантные данные для экономии дискового пространства
• Создавать кастомные анализаторы — комбинировать любой токенизатор с произвольной цепочкой фильтров

Пример ниже применяет стемминг английского языка к полям Text и Title, а поле с сырым HTML исключает из индексирования:

Результат buildIndexMapping() передаётся в bleve.New или bleve.NewUsing при создании индекса. Маппинги закрепляются за индексом на этапе создания и не могут быть изменены позже. Чтобы применить новый маппинг, нужно создать свежий индекс и переиндексировать все документы.

Мультиязычный поиск

Bleve умеет прозрачно работать с несколькими индексами одновременно через IndexAlias. Алиас — это виртуальный индекс, который отправляет запрос во все реальные индексы и объединяет результаты в единый ранжированный список.

Это особенно полезно, когда у каждого языка свой индекс с собственным анализатором (английский стемминг, французские стоп-слова, кастомная токенизация), а искать нужно по всем сразу:

Алиасы также упрощают горячую замену (hot-swap). Когда нужно перестроить индекс (например, применить новый маппинг), можно собрать новый индекс в фоне, а затем атомарно подменить его вызовом alias.Swap(newIndexes, oldIndexes). Текущие запросы завершатся на старом индексе, новые сразу пойдут на свежий — без даунтайма.

Пагинация с курсором

У SearchRequest в Bleve есть поле From для офсетной пагинации: 0 для первой страницы, 20 для второй и так далее. Это работает, но имеет серьёзную проблему: Bleve вынужден оценивать и сортировать все совпавшие документы вплоть до From + Size на каждый запрос. Глубокие страницы становятся всё дороже по памяти и CPU.

Хуже того, если между двумя запросами в индекс были добавлены новые документы, смещение сдвигается — и пользователь видит дубликаты или пропуски.

Правильный подход — курсорная пагинация через SearchAfter и SearchBefore. Эти методы продолжают выдачу с известной позиции, а не пересканируют результаты с начала:

На что обратить внимание:

• Стабильная сортировка обязательна. SearchAfter использует ключ сортировки последнего результата в качестве курсора. Если ключ нестабилен, курсор станет невалидным.
• Sort — всегда []string. Даже при сортировке по числовому полю Bleve сериализует ключ в строку. Читайте курсор из hit.Sort и передавайте напрямую в SetSearchAfter.
• SearchBefore работает аналогично, но в обратном направлении — полезно для кнопки «предыдущая страница».

Оптимизация производительности

Настройки производительности Bleve не слишком хорошо документированы, но существенно влияют на работу под нагрузкой. Конфигурация передаётся как map[string]any в NewUsing или OpenUsing вместо обычных New / Open.

Эти параметры относятся к Scorch — дефолтному бэкенду хранения Bleve. Полный список доступных опций и значений по умолчанию можно найти в исходном коде персистера.

Пакетная индексация

Если нужно проиндексировать большой объём данных, используйте Batch вместо одиночных вызовов Index. Пакетная запись группирует операции в одну транзакцию, что значительно снижает нагрузку на диск:

Оптимальный размер пакета зависит от объёма документов и доступной памяти. Как правило, пакеты по 100-1000 документов дают хороший баланс между скоростью и потреблением ресурсов.

Выводы

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

Официальная документация местами неполна, но issues на GitHub и реальные open-source-проекты отлично её дополняют. Рабочий пример всех описанных концепций можно найти в пакете indexer проекта Hister.

Адаптированный перевод статьи Data Indexing in Golang из блога Hister.

Это не абстрактный кейс из маркетингового блога. Это реальная история от Reco — SaaS-платформы безопасности, которая обрабатывает миллиарды событий в день. Их инженер Нир Барак взял подход, описанный Cloudflare в статье о переписывании Next.js с помощью ИИ, и применил его к собственной инфраструктуре. Получилась библиотека gnata — полная реализация JSONata 2.x на чистом Go с ускорением до 1000x на типовых выражениях.

JSONata — это язык запросов и трансформации JSON-данных. Его можно представить как jq, но с поддержкой лямбда-функций и более выразительным синтаксисом. JSONata позволяет писать сложные правила обработки данных без необходимости лезть в код основного приложения. Это делает его популярным в системах, где бизнес-аналитики или исследователи пишут правила детекции, а инженеры обеспечивают инфраструктуру.

Главное из статьи:

- JSONata-выражения через RPC обходились в $300 000/год на инфраструктуру
- ИИ-ассистированная перезапись на Go заняла 7 часов и стоила $400 в токенах
- Результат: 13 000 строк Go-кода, 1 778 пройденных тестов из официального набора
- Ускорение до 1000x на простых выражениях за счёт устранения RPC и JSON-парсинга
- Суммарная экономия после оптимизации пайплайна — $500 000/год

Проблема — JSONata как узкое место

У Reco есть policy engine, который проверяет JSONata-выражения на каждом событии в потоке данных. Миллиарды событий, тысячи различных выражений. Исследователи безопасности пишут правила детекции на JSONata, а инженеры обеспечивают их выполнение в реальном времени.

Загвоздка: референсная реализация JSONata написана на JavaScript, а весь пайплайн Reco — на Go. Годами компания держала в Kubernetes отдельный флот Node.js-подов (jsonata-js), к которым Go-сервисы обращались через RPC.

Для каждого события и каждого выражения это означало:

1. Сериализовать данные на стороне Go
2. Отправить по сети в Node.js-под
3. Выполнить JSONata-выражение
4. Сериализовать результат
5. Отправить обратно в Go-сервис

Во что это обходилось

Прямые затраты на инфраструктуру jsonata-js составляли около $300 000 в год, и сумма росла с каждым новым клиентом и правилом детекции. На одном из крупных кластеров количество реплик jsonata-js перевалило за 200 — и команда столкнулась с лимитом IP-адресов в Kubernetes.

Но денежные затраты были даже не главной проблемой. RPC round-trip занимает ~150 микросекунд ещё до начала вычисления. Для простого выражения вроде user.email = "admin@co.com", которое должно выполняться за наносекунды, основная цена — пересечение языковой границы. На масштабе Reco эти микросекунды складываются в ощутимые задержки.

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

Решение — переписать на Go с помощью ИИ

Толчком стала статья Cloudflare о том, как один инженер за неделю переписал API Next.js на Vite, потратив $1 100 на токены. Нир Барак прочитал её и понял: у Reco та же самая ситуация — есть спецификация, есть тестовый набор, нужна реализация на другом языке.

Подход: спецификация + тесты = контракт

Метод прямолинейный:

1. Портировать официальный тестовый набор jsonata-js на Go
2. Направить ИИ на реализацию, пока все тесты не пройдут
3. Добавить оптимизации, специфичные для Go и задачи Reco

В выходные Нир составил план, разбитый на «волны» (с помощью ИИ). На следующий день нажал «старт».

Инструменты и затраты

Конкретные модели и инструменты автор не раскрывает, но ключевые цифры говорят сами за себя:

• Время работы: 7 часов (один инженер)
• Стоимость токенов: $400
• Результат: 13 000 строк Go-кода
• Тесты: 1 778 пройденных тест-кейсов из официального набора jsonata-js

Библиотека получила название gnata — полная реализация спецификации JSONata 2.x на чистом Go.

Технические результаты

Двухуровневая архитектура вычислений

gnata использует двухуровневую архитектуру оценки выражений. На этапе компиляции каждое выражение анализируется и классифицируется.

Быстрый путь (fast path) обрабатывает простые выражения: поиск по полям, сравнения и 21 встроенную функцию на чистых путях (например, $exists(a.b) или $lowercase(name)). Эти выражения вычисляются прямо по сырым JSON-байтам, без полного парсинга документа. Для выражения вроде account.status = "active" результат — ноль аллокаций в куче.

Полный путь (full path) — полноценный парсер и вычислитель с полной семантикой JSONata 2.x. Он парсит JSON, но только нужные поддеревья, а не весь документ целиком.

Потоковая обработка

Поверх двухуровневой оценки работает потоковый слой (StreamEvaluator), спроектированный под конкретную задачу Reco: применить N скомпилированных выражений к каждому событию, где события структурно похожи.

• Все пути из всех выражений объединяются в один проход по данным — количество выражений не влияет на скорость чтения
• После прогрева горячий путь работает без блокировок (lock-free)
• Планы вычислений создаются один раз на схему событий и кэшируются неизменяемо — чтение через один атомарный load без синхронизации
• Память ограничена: кэш с настраиваемой ёмкостью, вытесняющий старые записи

Бенчмарки

Ускорение на простых выражениях — в основном за счёт полного устранения RPC: gnata вычисляет прямо по сырым байтам без парсинга JSON. На сложных выражениях, где нужен полный парсинг и AST-вычисление, разрыв сужается, но они всё равно в 25–90 раз быстрее, чем через RPC.

На простых lookups ускорение достигает 1000x.

Пример использования

Экономический эффект

Этап 1: устранение RPC-флота

Первый и самый очевидный эффект — полное устранение jsonata-js подов в Kubernetes:

• До: ~$25 000/мес на compute для jsonata-js (200+ реплик Node.js)
• После: $0 — gnata работает как библиотека внутри существующих Go-сервисов
• Экономия: ~$300 000/год

Этап 2: рефакторинг rule engine

Но на этом история не закончилась. Старый JSONata через RPC мог обрабатывать только одно выражение за раз, и вся инфраструктура вокруг него была вынуждена подстраиваться. Rule engine запускал десятки тысяч горутин для максимизации параллелизма — со всеми вытекающими: избыточное потребление памяти и высокая конкуренция за CPU.

gnata не имеет таких ограничений. Команда заменила внутренности rule engine на более простую и эффективную реализацию с just-in-time батчингом (паттерн request coalescing), короткоживущими кэшами и групповыми запросами обогащения данных.

Результат: ещё ~$18 000/мес, или ~$200 000/год экономии.

Итого

$500 000/год снято с пайплайна за две недели работы. Из них 7 часов — создание gnata, остальное — тестирование, code review и раскатка.

Как внедряли — от shadow mode до продакшена

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

У Reco уже была инфраструктура для shadow-тестирования: feature flags, параллельное вычисление, логирование расхождений. Подключить gnata к ней было несложно.

Хронология раскатки:

• День 1: gnata готова, PR открыт
• Дни 2–6: code review, QA на реальных продакшен-выражениях, деплой в preprod в shadow mode. gnata вычисляет всё, но результаты jsonata-js остаются основными. Расхождения логируются и алертятся. Найденные edge-кейсы исправляются
• День 7: три дня подряд ноль расхождений. gnata переведена в primary

К моменту перевода gnata уже обработала миллиарды событий и выдала идентичные результаты. Более того, в процессе обнаружились баги в самом jsonata-js — случаи, где референсная реализация не соответствует собственной спецификации.

Побочный эффект: gnata стала одним из первых крупных PR в Reco, где ИИ-агенты ревьюили ИИ-сгенерированный код. Агенты помечали всё подряд — и реальные проблемы с конкурентностью, и косметические замечания. Команде пришлось научить их отличать одно от другого, и этот опыт теперь используется шире.

Уроки — когда ИИ-переписывание работает

gnata — удачный кейс. Но не каждая задача подходит для ИИ-переписывания. Вот что сделало этот проект идеальным кандидатом:

1. Чёткая спецификация. JSONata имеет формальную спецификацию и обширный тестовый набор. ИИ не нужно придумывать поведение — нужно реализовать заданное
2. Детерминированная проверка. Каждое выражение имеет однозначный правильный ответ. Можно автоматически проверить корректность — не нужен человек для оценки каждого результата
3. Глубокая экспертиза инженера. Нир не просто «нажимал кнопку». Он спроектировал двухуровневую архитектуру, потоковую обработку и стратегию кэширования. ИИ генерировал код, но архитектурные решения принимал человек
4. Существующая инфраструктура тестирования. Shadow mode, feature flags, сравнение результатов — всё это было готово до gnata. Без этого раскатить ИИ-сгенерированный код в продакшен было бы рискованно
5. Ограниченная область. JSONata — это чётко ограниченная задача. Не «перепишите весь бэкенд», а «реализуйте этот конкретный язык на другом стеке»

Как отметил Андрей Карпати: программирование становится неузнаваемым, и на верхних уровнях глубокая техническая экспертиза — «ещё больший мультипликатор, чем раньше, из-за увеличенного рычага». gnata — хорошая иллюстрация этой мысли.

FAQ

Что такое JSONata и зачем он нужен?

JSONata — это язык запросов и трансформации для JSON-данных. Он позволяет писать выражения для фильтрации, преобразования и агрегации JSON без написания кода на языке общего назначения. Используется в IoT-платформах, ETL-пайплайнах и системах обработки событий.

Почему нельзя было просто оптимизировать существующий подход?

Reco пробовали: оптимизация выражений, кэширование, встраивание V8 в Go. Всё это давало инкрементальные улучшения, но корневая проблема — пересечение языковой границы через RPC — оставалась. Единственное радикальное решение — нативная реализация на Go.

Насколько gnata совместима с оригинальной JSONata?

gnata проходит 1 778 тест-кейсов из официального набора jsonata-js и 2 107 интеграционных тестов в продакшен-обёртке Reco. В процессе тестирования были обнаружены баги в самом jsonata-js, где референсная реализация не соответствует собственной спецификации.

Можно ли повторить этот подход в другом проекте?

Да, если есть формальная спецификация и тестовый набор. Подход Cloudflare (vinext) и Reco (gnata) одинаков: берём спеку + тесты, направляем ИИ на реализацию до прохождения всех тестов. Ключевое требование — детерминированная проверка результата.

Выводы

История gnata — это не про то, что ИИ «волшебным образом» пишет продакшен-код. Это про то, как опытный инженер с глубоким пониманием задачи использует ИИ как мультипликатор своей экспертизы.

Ключевые выводы:

• ИИ-переписывание работает, когда есть чёткая спецификация и автоматизированная проверка
• Экономический эффект может быть огромным: $400 на токены превратились в $500 000/год экономии
• Архитектура важнее генерации кода: двухуровневая оценка, потоковая обработка и батчинг — решения инженера, не ИИ
• Shadow mode обязателен: ИИ-сгенерированный код нельзя просто «выкатить» — нужна параллельная проверка на реальных данных
• ROI считается просто: если задача имеет спеку и тесты, стоимость ИИ-переписывания предсказуема

gnata доступна как open-source библиотека: github.com/RecoLabs/gnata.

Источник: We Rewrote JSONata with AI — блог Reco.

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

Разберём возможные варианты взаимодействия клиента с сервером для обработки больших объектов, в нашем случае это картинки:

1. HTTP/1.1 (REST)

Передача изображений в виде текстовых чанков (например, base64) приводит к значительным накладным расходам: бинарные данные увеличиваются на ~33% при кодировании в Base64, а текстовый формат неэффективен для больших объёмов.

2. WebSocket

Подходит для долгоживущих сессий и двустороннего обмена, но избыточен, если нам нужно просто «принять изображение → обработать → вернуть результат». Удержание тысяч соединений ради однократных операций — неоптимально.

3. gRPC использует:

Protocol Buffers — строго типизированный, компактный бинарный формат,

HTTP/2 — мультиплексирование, потоки, сжатие заголовков,

Client-Streaming — идеально подходит для передачи одного большого файла (например, изображения) в одном вызове.

I. Постановка задачи

Сервис должен:

Принимать изображение и параметры (format, compress, watermark, width[], height[]),

Сохранять оригинал с уникальным путём (./download/YYYY/MM/DD/UUID/img/...),

Накладывать водяной знак,

Генерировать версии заданных размеров,

Сохранять полученные изображения,

Возвращать список путей.

Пример:

Запрос с width = [1920, 1280], height = [1080, 720], format = "webp", watermark = "logo.png"

→ Сервис вернёт два пути:

./download/2026/02/08/abc123/img/abc123_1920x1080.webp

./download/2026/02/08/abc124/img/abc124_1280x720.webp

II. Архитектура приложения

Обработка происходит в строгом порядке:

1.Приём → 2. Сохранение исходного файла→ 3. Сжатие → 4. Watermark → 5. Resize → 6. Конвертация → 7. Ответ.

Структура хранения:

./download/2026/02/08/a1b2c3d4-.../img/

├── a1b2c3d4-....jpg ← оригинал

├── a1b2c3d4-..._800x600.png

└── a1b2c3d4-..._1024x768.png

Необходимые инструменты:

Для работы с WebP мы используем библиотеку golang.org/x/image/webp , а исходные утилиты можно скачать на официальной странице Google.

Для генерации protobuff нам нужен protoc-gen-go

protoc-gen-go-grpc

Позволяет генерировать определения сервисов Go для буфера протокола, заданного нашим .proto файлом protoc-gen-go-grpc

Также для работы webp нам потребуется работа с CGO, которую мы рассмотрим отдельно.

III. Реализация proto файла

Для начала работы опишем наш proto файл. Это будет сервис с единственным rpc который будет обрабатывать картинки пользователей.

./proto/image.proto

Мы используем Client-Streaming RPC — клиент может отправить несколько сообщений, сервер — один ответ. Этот способ поможет нам в случае необходимости гибкого расширения и избежания ограничений на размер одного сообщения.

V. Реализация основных функций

1. Создание сервера

1.1 Генерация go файлов из .proto: Сгенерируем файлы для реализации сервера с помощью protoc:

У нас должно получиться 2 файла image.pb.go и image_grpc.pb.go в директории proto

1.2 Реализуем конструктор сервера и interceptor (аналог middleware в grpc) восстановления после паники:

./internal/app/server.go

Теперь реализуем функцию запуска нашего grpc сервера:

Мы создали наш grpc сервер, но пока нет никакой реализации ImageServiceServer который сгенерировал нам protoc, это просто интерфейс который нам и нужно реализовать.

2. Реализация ImageServiceServer

Нам необходимо создать структуру ImageServer которая реализует интерфейс ImageServiceServer с его методом DownloadImage, также создадим конструктор для него :

./internal/app/image.go

Нам осталось реализовать ключевые функции для нашего сервиса, а именно: saveSourceFiles: отвечает за сохранение исходных файлов и их сжатие, watermark: наложение ватермарки , resizeAndSave: изменения размера картинки и его конвертация в нужный формат изображения.

3. Сохранение оригинала

Мы создаем путь для сохранения картинки, сохраняем её с необходимым для клиента уровнем сжатия и потом для удобства всю метаинформацию об картинке помещаем уже в нашу структуру и работаем в дальнейшем только с ней:

./internal/app/save.go

Для ускорения нашего процесса обработки все этапы мы будем выполнять конкурентно с помощью горутин.

4. Водяной знак

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

./internal/app/watermark.go

Остаётся только изменить размер и сохранить в нужном формате наши обработанные изображения.

5. Resize и конвертация.

Теперь создадим файл resize.go и реализуем функцию изменения размера изображении и сохранения в нужном нам формате:

./internal/app/resize.go

Теперь реализуем main.go в котором создадим и вызовем наш сервис обработки изображений.

./internal/cmd/main.go

VI. CGO

Наше приложение полностью готово, но теперь нужно удостовериться, что у нас работает поддержка CGO. Для начала нужно убедиться что мы скачали и установили webp по ссылке [официальная страница Google](https://developers.google.com/speed/webp/download?hl=ru). Далее нам необходимо установить GCC, без него go не может распознать импортированные C файлы, скачиваем и устанавливаем [официальные зеркала GNU](https://gcc.gnu.org/mirrors.html). Теперь нужно проверить, что переменная CGO_ENABLED=1, для этого используем команду go env и проверяем, если она равна 0, то используем go set CGO_ENABLED=1 и проверяем ,что она применилась, если нет то перезагружаем нашу систему и проверяем. Теперь мы готовы собрать наше приложение и приступить к тестированию.

VII. Тестирование и оптимизация

Тестирование с Bruno

Здесь вы можете тестировать удобными для вас средствами такими как Postman, Bruno, Yaak, grpccurl и т.д., главное чтобы они поддерживали тестирование grpc методов. Рассмотрим пример с Bruno:

1.Конвертируйте изображение в Base64: Image to Base64 Converter

2.Откройте Bruno создайте новый grpc запрос

3. Выбираем метод grpc:

4.Уберите ползунок с reflection и укажите .proto файл

5.Выберите метод DownloadImage

6.В поле message заполните поле в соответствии с параметрами, например:

В поле image нужно скопировать текстовую строку ,что идёт после запятой, сгенерированную на шаге 1

7.Далее нужно запустить наше приложение и подключиться к нему с помощью кнопки →

В случае успеха должен появиться статус streaming

8.Отправляем наше сообщение/сообщения нажав на кнопку "Send message" один или несколько раз и завершаем нашу передачу сообщений с помощью кнопки → (если не нажать то приложение будет ожидать приёма сообщений). Результатом будет возврат путей наших обработанных сообщений

VIII. Заключение

Подведем итоги, мы создали сервис который:

Использует gRPC для эффективной передачи данных,

Поддерживает WebP, JPEG, PNG,

Безопасен в конкурентной среде,

Можно легко масштабировать.

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

Исходный код доступен по ссылке

Спасибо за внимание!

Новые фичи, интеграции, поддержка Kubernetes и облаков сделали продукт мощнее... и заметно тяжелее. Это стало проблемой для serverless, IoT и контейнеров.

Вместо того чтобы урезать функциональность, команда решила «переломить кривую роста». За полгода (v7.60.0 → v7.68.0) им удалось сократить размер Go-бинарников до 77%.

Аудит зависимостей: минус 36 МБ одной правкой

Первый шаг — полный разбор зависимостей. С помощью go list, goda и go-size-analyzer разработчики искали пакеты, которые подтягиваются в бинарник случайно.

В одном случае trace-agent тащил 526 пакетов Kubernetes из-за одной функции, которая фактически не использовала k8s-код. Перенос ее в отдельный пакет позволил компилятору выбросить все лишнее — минус 36 МБ.

И таких случаев нашли десятки.

Разблокировка «скрытой» оптимизации линкера

Вторая находка дала еще ~20% выигрыша. В Go есть оптимизация method dead code elimination, но она отключается, если используется reflect.MethodByName с динамическими именами (например, в text/template).

Команда нашла проблемные вызовы через -dumpdep и утилиту whydeadcode, пропатчила зависимости и даже форкнула text/template, чтобы отключить динамические вызовы методов. Результат — еще минус около 100 МБ.

Удаление plugin = минус 245 МБ

Самый неожиданный эффект дал пакет plugin. Его импорт заставлял линкер сохранять все методы типов, отключая оптимизацию.

Выяснилось, что зависимость приходила через containerd, хотя агент ее не использовал. После добавления build-тега и обновления зависимостей, основной Linux amd64-бинарник «похудел» на 245 МБ.

Итог

• Security Agent: −77%
• Process Agent: −74%
• Trace Agent: −74%
• Общий .deb: 1,22 ГБ → 688 МБ

И главное — все это без удаления функций. Только системная чистка зависимостей, грамотные build-теги и возвращение оптимизаций линкера.

Go стал очень популярным языком для бэкенд-API, потому что он предоставляет:

• Очень высокая производительность (компилируемый язык)
• Простой параллелизм с помощью горутин
• Простое развертывание (один бинарный файл)
• Отлично подходит для микросервисов и облачных приложений

Такие крупные компании, как Google, Uber, Twitch, Dropbox, активно используют Go для серверных сервисов.

5 лучших веб-фреймворков Go в 2026 году

Gin — безопасный выбор по умолчанию

Сайт → https://gin-gonic.com/

GitHub → https://github.com/gin-gonic/gin

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

Скорость изучения: 1–2 дня

Идея для бенчмарка: ~50–70 тыс. запросов в секунду

Преимущества 👍

• Очень прост в настройке

• Огромное сообщество и промежуточное ПО

• Стабилен и проверен в реальных условиях

• Работает со стандартной экосистемой net/http

Недостатки 👎

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

• Отсутствие встроенной системы внедрения зависимостей

• Некоторым не нравится стиль с использованием контекста

Fiber — стиль Express.js для Go

Сайт → https://gofiber.io/

GitHub → https://github.com/gofiber/fiber

Fiber похож на Express.js, но написан на Go. Если вы знакомы с Node.js, он вам понравится.

Скорость обучения: 1 день

Идея бенчмарка: ~70–110 тыс. запросов в секунду

Преимущества 👍

• Чрезвычайно быстрый

• Очень удобен для разработчиков на Node

• Множество встроенных функций

• Чистый и простой синтаксис

Недостатки 👎

• Использует fasthttp вместо net/http

• Некоторые библиотеки Go не работают

• Отладка может быть затруднена

• Экосистема меньше, чем у Gin

Echo — чистый и продуманный фреймворк

Сайт→ https://echo.labstack.com/

GitHub → https://github.com/labstack/echo

Echo — это сбалансированный фреймворк. Не слишком маленький, не слишком большой.

Скорость изучения: 2–3 дня

Идея бенчмарка: ~50–65 тыс. запросов в секунду

Преимущества 👍

• Чистая структура

• Встроенная система проверки и промежуточное ПО

• Хорошая документация

• Развитая и стабильная

Компромиссы 👎

• Экосистема меньше, чем у Gin

• Для некоторых расширенных функций требуются дополнительные библиотеки

• Не такой быстрый, как Fiber

Chi — легковесный маршрутизатор для чистой архитектуры

Сайт → https://go-chi.io/

GitHub → https://github.com/go-chi/chi

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

Время обучения: несколько часов

Идея бенчмарка: ~45–60 тыс. запросов в секунду

Преимущества 👍

• Очень легкий

• Использует стандартную сеть/http

• Идеально подходит для чистой архитектуры

• Простое тестирование

Компромиссы 👎

• Не подходит для новичков

• Все нужно создавать самостоятельно

• Нет встроенной объектно-реляционной модели или вспомогательных инструментов

• Медленное начало работы над небольшими проектами

Beego — полноценный MVC-фреймворк

Сайт → https://beego.vip/

GitHub → https://github.com/beego/beego

Beego похож на Django. В нем есть ORM, интерфейс командной строки, сессии, шаблоны.

Скорость освоения: 1–2 недели

Идея бенчмарка: ~20–40 тыс. запросов в секунду

Преимущества 👍

• Все встроено

• Быстрая разработка монолитных приложений

• Хорошие инструменты командной строки

• Встроенная объектно-реляционная модель и шаблоны

Компромиссы 👎

• Более низкая производительность

• Больше весит по сравнению с Gin или Fiber

• Сегодня сообщество меньше

• Не подходит для микросервисов

Откуда взяты эти показатели производительности

Приведенные выше цифры не случайны. Вы можете проверить их здесь:

👉 https://www.techempower.com/benchmarks/

Это самый надежный бенчмарк в сфере бэкенд-разработки. Он тестирует фреймворки на одном и том же оборудовании с одинаковой нагрузкой.

Но помните ⚠️

Реальная производительность зависит от:

• использования базы данных

• ведения журналов

• аутентификации

• размера полезной нагрузки

• TLS

• аппаратного обеспечения

Поэтому всегда проводите собственное тестирование.

Мои рекомендации на 2026 год:

- Если вы новичок → начните с Gin

- Если вам нужна максимальная производительность → попробуйте Fiber

- Если вам нужна сбалансированная структура → используйте Echo

- Если вам нравится чистая архитектура → используйте Chi

- Если вам нужен полноценный MVC → используйте Beego

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

Перевод статьи

Новый GC по умолчанию: минус до 40% накладных расходов

Так, в релизе включён сборщик мусора greenteagc. Он оптимизирован для частого создания и сканирования мелких объектов.

В приложениях с активной аллокацией это даёт снижение накладных расходов GC на 10–40%. Если у вас сервис с короткоживущими структурами, это обновление может стать бесплатным ускорением, без изменения кода.

cgo стал дешевле

Вызовы функций на C через cgo также подешевели примерно на 30%. Это важно для проектов, которые тянут нативные библиотеки (криптография, обработка изображений, старый C-код).

Дополнительно в runtime для 64-битных платформ включили рандомизацию адресного пространства (heap base). Это усложняет эксплуатацию уязвимостей в C-коде, подключённом через cgo. При необходимости можно отключить через:

new() теперь умеет принимать выражения

Встроенная функция new() получила маленькое, но приятное расширение: теперь можно передать выражение для начального значения.

Было:

Теперь можно:

Мелочь, но код становится компактнее и чище.

Обобщённые типы: разрешили «ссылаться на себя»

Generics стали чуть гибче. Теперь тип может передавать сам себя в список параметров типа:

Раньше такая самоссылка вызывала ошибку. Теперь — нет. Для сложных generic-алгоритмов это снимает лишние ограничения.

Больше аллокаций в стеке, меньше в куче

Компилятор расширил список случаев, когда слайсы размещаются в стеке, а не в куче. А так как меньше давления на GC, то и выше производительность.

go fix переписали полностью

Команду go fix переписали на базе пакета analysis. Теперь она использует анализаторы из пакета modernize, которые предлагают правки с учётом новых возможностей языка и стандартной библиотеки.

Также появился анализатор inline — он разворачивает вызовы функций, помеченных директивой:

Новые пакеты

В стандартную библиотеку добавили:

• crypto/hpke — реализация Hybrid Public Key Encryption
• crypto/mlkem/mlkemtest
• testing/cryptotest

Появился экспериментальный simd/archsimd — низкоуровневый доступ к SIMD-инструкциям на AMD64. Это первый осторожный шаг Go в сторону управляемых векторных вычислений без ассемблера.

Также добавили экспериментальный runtime/secret для безопасного обнуления временной памяти и новый профиль goroutineleak в runtime/pprof — для поиска утечек горутин.

Скачать Go 1.26 можно по ссылке.

Найти топ-специалистов в ИТ — задача сложная, особенно когда нужны люди со специфическими навыками и знанием английского. Островок решил эту задачу через O!Хакатон — единственный в России регулярный travel-tech хакатон, который проводится уже два года подряд. Это полностью внутренний проект: от разработки архитектуры бота до продвижения силами собственных сотрудников.

Команда из 5 человек за 8–9 месяцев готовит ивент, который собирает тысячи регистраций и сотни участников со всего мира. Последний хакатон показал ВАУ результаты: 1,4 млн охвата в промо и технические решения, одно из которых эксперты назвали «невозможным для реализации за неделю».

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

Задача: привлечь профи и показать реальный travel-tech

Бизнес-цель — транслировать ценности компании на широкую ИТ-аудиторию и привлечь подходящих кандидатов. Островок быстро растет, и конкуренция за специалистов высокая. Хакатон помогает качественно погрузить аудиторию в задачи бизнеса, познакомить со стеком и командой в неформальной обстановке.

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

Параметры проекта

• Срок подготовки: 8–9 месяцев.
• Команда: в основной команде было 8 сотрудников, которые еженедельно работали над проектом. Кроме этого, во время хакатона 18 экспертов оценивали задания участников.
• Технологический стек: Go+PocketBase (backend бота), Next.js (лендинг) и LLM для проверки кода.
• Охват: 1,4 млн человек в промо.
• Результаты: 800 регистраций, 19 тыс. визитов на лендинг и прямой найм в команду.
• Статус: ежегодный проект, следующее мероприятие в сентябре 2026 года .

Архитектура: бот на Go и микропотребление ресурсов

Для управления хакатоном разработали специального Telegram-бота:

1. Бэкенд: Написан на Go с использованием фреймворка PocketBase.
2. Скорость разработки: Благодаря помощи LLM на создание и поддержку бота ушло всего 8 часов чистого времени.
3. Ресурсы: Бот потребляет всего 10MB RAM и минимум ресурсов процессора, стабильно работая при больших нагрузках.
4. Интеграции: Автоматическая выдача прав в GitHub для участников прямо через Telegram.

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

Три главных технических фишки

1. LLM как ассистент жюри

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

2. Полная автоматизация в Telegram

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

3. Инхаус-реализация промо

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

Трудности и решения

🔴 Проблема: Нехватка данных после регистрации

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

✅ Решение: Обновленная форма регистрации

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

🔴 Проблема: Однотипные вопросы от участников

Участники часто задавали одни и те же вопросы о правилах, сроках и формате участия.

✅ Решение: Шаблоны и гайды

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

Итоги и планы на сентябрь

Второй О!Хакатон побил собственный рекорд по количеству участников: 460 команд удивили экспертов разнообразием подходов к выполнению travel tech-задач. Все финалисты показали высокий уровень навыков и порадовали креативом: один из участников в качестве бонуса реализовал «Tinder для отелей».

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

Следите за новостями в Telegram-канале проекта, чтобы не пропустить старт регистрации 2026!

Реклама. ООО «Бронирование Гостиниц», ИНН 7703389880, erid: 2W5zFFwA6N5

Java: 15 самых популярных докладов 2025 года на YouTube

В 2025 году вокруг Go много движется именно в рантайме и инструментах: язык остаётся максимально прикладным и ориентированным на продакшен.

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

1. What’s coming in Go 1.25 — Daniel Marti

Конференция - 9500 просмотров - 17 сентября 2025 - 51 минута​

Доклад даёт технический обзор изменений в языке, тулчейне и стандартной библиотеке Go 1.25: новые итераторы, стабильный PGO (profile-guided optimization), улучшения компилятора, поддержка FIPS и доработки рантайма. Спикер подробно объясняет, что попало в релиз в августе и почему это важно для команд, которые используют Go в энтерпрайзе.

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

2. Building a coding agent from scratch — Bill Kennedy

Конференция - 3700 просмотров - 18 сентября 2025 - 49 минут

Живой live-coding‑доклад о том, как собрать практичного «кодового агента» на базе Ollama и gpt-oss. Пошагово показывается, как научить агента читать файлы, листать структуру проекта, вносить правки в код и вызывать инструменты, при этом объясняются принципы tool calling и reasoning.

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

3. The Things I Find Myself Repeating About Go — Dave Cheney | GopherCon EU 2025

Конференция - 3400 просмотров - 9 сентября 2025 - 31 минута

Опытный Go-разработчик делится тем, что повторяет снова и снова: идиомы, подходы к неймингу, структуре пакетов и организации кода. Разбираются main.run‑паттерн, guard‑clause стиль, как лучше раскладывать файлы и пакеты, когда использовать вспомогательные функции и дженерики вместо копипасты, и как мышление влияет на стиль Go-кода.

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

4. Unleashing the Go Toolchain — Kemal Akkoyun

Конференция - 2800 просмотров - 18 сентября 2025 - 59 минут

Доклад показывает, как через флаг toolexec превратить каждый go build в программируемый пайплайн. На реальных проектах демонстрируется, как внедрять кастомный анализ, генерацию кода и хуки наблюдаемости прямо на этапе компиляции, не убивая скорость сборки.

Почему стоит посмотреть: если хотите выжать из Go‑тулчейна максимум — автогенерировать куски инфраструктуры, внедрять свои линтеры и метрики — это практическое руководство по расширению стандартных инструментов.

5. Observability made painless: Go, Otel & LGTM stack — Haseeb Majid

Конференция - 2800 просмотров - 18 сентября 2025 - 1 час 00 минут

Практический разбор, как использовать Go‑сервисы с помощью OpenTelemetry и LGTM‑стека (Loki, Grafana, Tempo, Mimir и т.п.). Спикер показывает, когда использовать трассировки, метрики или логи, зачем в этом всём context.Context и какие практики помогают строить масштабируемую телеметрию без сложной теории.

Почему стоит посмотреть: если у вас микросервисы на Go и хаос в логах, доклад даёт конкретный план, как выстроить наблюдаемость, не утонув в инструментах.

6. The Right Kind of Abstraction — John Cinnamond

Конференция - 2300 просмотров - 17 сентября 2025 - 46 минут

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

Почему стоит посмотреть: помогает не городить лишние уровни интерфейсов, сохраняя код простым и поддерживаемым.

7. Go Security – Past, Present, and Future — Roland Shoemaker

Конференция - 2000 просмотров - 17 сентября 2025 - 31 минута

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

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

8. Swiss Maps in Go — Bryan Boreham

Конференция - 1900 просмотров - 18 сентября 2025 - 49 минут

Доклад показывает, как переработанные Go‑maps (так называемые Swiss Maps в Go 1.24) используют битовые трюки и SIMD‑оптимизации в компиляторе, чтобы выжать максимум производительности из CPU. Спикер также подробно разбирает подводные камни нового поведения, о которых важно знать.

Почему стоит посмотреть: если вы упираетесь в производительность, активно используете map и хотите понимать, как они устроены под капотом, это отличный технический разбор.

9. How Just Eat uses tooling to deploy Go micro-services in minutes — Ainsley Clark

Конференция - 1600 просмотров - 18 сентября 2025 - 42 минуты

На примере Just Eat показывается, как их внутренний тулкит для микросервисов на Go помогает быстро поднимать сервисы, настраивать event‑driven‑воркфлоу и автоматически генерировать инфраструктуру как код и CI/CD. В результате сложные системы реально деплоятся за минуты, а не недели.

Почему стоит посмотреть: если вы строите платформу для микросервисов на Go, здесь можно подсмотреть архитектуру, пайплайны и подход к автоматизации.

10. Climbing the Testing Pyramid: From Real Service to Interface Mocks in Go — Naveen Ramanathan

Конференция - 1400 просмотров - 17 сентября 2025 - 48 минут

Доклад про тестирование Go‑сервисов, работающих с S3 и другими внешними системами. Пошагово показываются стратегии: от тестов против реального S3 и хаоса через Toxiproxy до LocalStack, httptest/httpmock и генерации моков по интерфейсам, чтобы честно проверять отказоустойчивость.

​Почему стоит посмотреть: если вы не уверены, как правильно тестировать интеграции и ошибки в Go‑сервисах, этот доклад даёт понятную лестницу подходов, от реальных окружений до быстрых моков.

11. When Failure Is Not an Option: Surviving Cloud Outages in Go — Kevin Holditch

Конференция - 1300 просмотров - 18 сентября 2025 - 30 минут

Реальная история команды, которая ушла с single‑cloud Java‑решения на multi‑cloud платформу на Go: активная/активная/активная архитектура на Kubernetes, CockroachDB и NATS, чтобы выдерживать банковские SLA. Команда гоняет 24‑часовые «kill‑тесты» провайдеров прямо в продакшене.

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

12. Hello, MCP World! — Daniela Petruzalek

Конференция - 1300 просмотров - 17 сентября 2025 - 30 минут

Model Context Protocol (MCP) — попытка стандартизировать, как приложения общаются с LLM‑моделями. Доклад разбирает клиент‑серверные компоненты, транспорта, инструменты, промпты и ресурсы, показывая практические примеры на Go для AI‑ассистируемого кода и текста.

Почему стоит посмотреть: если вы хотите встроить LLM в Go‑приложения через понятный протокол, это хорошая точка входа.

13. Deep dive into a Go binary — Jesús Espino

Конференция - 1200 просмотров - 18 сентября 2025 - 49 минут

Глубокое погружение в то, как устроен бинарник Go: ELF‑секции, метаданные рантайма и трюки линковки, которые спрятаны внутри исполняемого файла. Подойдёт тем, кто любит разбирать, что происходит после go build.

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

14. The Quest for Speed: Journey to 50% Better P99 Times with Go — David Vella

Конференция - 1200 просмотров - 17 сентября 2025 - 50 минут

Инженерный постмортем, как команде удалось вдвое улучшить P99‑латентность сервиса на Go. Разбираются профилирование, реальные метрики, типичные анти‑паттерны, которые убивали производительность, и конкретные исправления.

Почему стоит посмотреть: если у вас есть медленный, но рабочий Go‑сервис, доклад даёт чек-лист, по которому можно пройтись и вытащить реальные проценты по скорости.

15. A Gopher’s Guide to Vibe Coding — Daniela Petruzalek

Конференция - 1100 просмотров - 18 сентября 2025 - 1 час 01 минута

Vibe coding — модный термин, когда большую часть кода за вас пишет LLM, а вы больше управляете процессом и допиливаете результаты. В докладе делятся опытом нескольких месяцев такой работы: плюсы и минусы, влияние на скорость, качество, идиоматичность Go-кода, поддерживаемость и тестируемость, плюс практические советы по промптам и контексту.

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

Итого вы получили 15 докладов, которые покрывают все актуальные направления современного Go — от новых возможностей Go 1.25 и оптимизации производительности до интеграции с AI-агентами, построения высокодоступных multi-cloud систем и работы с современным стеком наблюдаемости.

В следующей части — 15 самых просматриваемых докладов по Rust, где язык выходит за границы системного программирования и захватывает веб, десктоп и корпоративные платформы.

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

Языки программирования отличаются по многим параметрам, и сравнивать их сложно, не скатываясь к совершенно скучному или бесполезному выводу “везде есть компромиссы”. Конечно, компромиссы есть всегда. Интересный вопрос — почему этот конкретный язык выбрал именно такой набор компромиссов?

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

Этот вопрос также помогает прояснить разницу между языками, которые на первый взгляд сильно пересекаются по возможностям. Судя по количеству вопросов статей вроде “Go или Rust” и “Rust или Zig”, люди тоже не понимают, что происходит. Сложно запомнить, что язык X лучше для веб-сервисов, потому что у него есть фичи a, b и c, а у языка Y только a и b. Гораздо проще запомнить, что язык X лучше для веб-сервисов, потому что язык Y создан человеком, который ненавидит интернет (условно) и считает, что нужно вырубить всю сеть.

Я собрал здесь мнение о трёх языках, с которыми недавно экспериментировал: Go, Rust и Zig. Я попытался превратить свой опыт с каждым языком в общий вывод о том, что этот язык представляет из себя и насколько хорошо реализует свои ценности. Да, это упрощение, но кристаллизация упрощённых предубеждений — именно то, что я здесь и делаю.

Go: минимализм для корпораций

Go выделяется своим минимализмом. Его называют “современным C”. Go не похож на C, потому что у него есть сборщик мусора и полноценная среда выполнения, но он похож на C тем, что весь язык помещается в голове.

Весь язык помещается в голове, потому что в Go очень мало возможностей. Долгое время Go был известен отсутствием дженериков. Их наконец добавили в Go 1.18, но только после 12 лет, в течение которых люди умоляли это сделать. Другие возможности, обычные для современных языков — например, размеченные объединения (tagged unions) или синтаксический сахар для обработки ошибок — в Go так и не появились.

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

Ещё один пример минимализма Go — тип slice. И в Rust, и в Zig есть slice, но это толстые указатели (fat pointers) и только они. В Go slice — это толстый указатель на непрерывную последовательность в памяти, но slice также может расти. То есть он объединяет функциональность типа Vec<T> из Rust и ArrayList из Zig. Кроме того, поскольку Go управляет памятью за вас, он сам решает, где будет жить память вашего slice — в стеке или куче. В Rust или Zig вам придётся сильно задуматься, где живёт ваша память.

История происхождения Go, насколько я понимаю, примерно такая: Роб Пайк устал ждать компиляции проектов на C++ и устал от ошибок, которые другие программисты Google делали в тех же проектах на C++. Поэтому Go прост там, где C++ перегружен. Это язык для рядовых программистов, спроектированный быть достаточным для 90% задач и при этом простым для понимания, даже (или особенно) при написании конкурентного кода.

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

Rust: максимализм ради безопасности

Если Go минималистичен, то Rust максималистичен. Популярный слоган Rust — “абстракции с нулевой стоимостью” (zero-cost abstractions). Я бы дополнил: “абстракции с нулевой стоимостью, и их очень много!”

У Rust репутация сложного для изучения языка. Я согласен с Джейми Брэндоном, который пишет, что Rust делает сложным не система времён жизни (lifetimes), а количество концепций, запиханных в язык. Я не первый, кто приводит в пример этот конкретный комментарий на GitHub, но он идеально показывает концептуальную плотность Rust:

Тип Pin<&LocalType> реализует Deref, но не реализует DerefMut. Типы Pin и & помечены #[fundamental], так что возможна реализация DerefMut для Pin<&LocalType>>. Вы можете использовать LocalType == SomeLocalStruct или LocalType == dyn LocalTrait, и можете привести Pin> к Pin>. (Действительно, два слоя Pin!!) Это позволяет создать пару “умных указателей, реализующих CoerceUnsized, но имеющих странное поведение” на стабильной версии (Pin<&SomeLocalStruct> и Pin<&dyn LocalTrait> становятся умными указателями со «странным поведением», и они уже реализуют CoerceUnsized).

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

Цель производительности понятна сама по себе. Что означает “безопасность” — менее очевидно, по крайней мере для меня (хотя, может быть, я просто слишком долго писал на Python). “Безопасность” означает “безопасность памяти” — идею, что вы не должны иметь возможность разыменовать невалидный указатель или сделать двойное освобождение памяти. Но это также означает больше. “Безопасная” программа избегает всего неопределённого поведения (undefined behavior, или UB).

Что такое ужасное UB? Лучший способ понять это — вспомнить, что для любой работающей программы ЕСТЬ СУДЬБЫ ХУЖЕ СМЕРТИ. Если в программе что-то идёт не так, немедленное завершение — это прекрасно! Потому что альтернатива, если ошибка не поймана — ваша программа переходит в сумеречную зону непредсказуемости, где её поведение может определяться тем, какой поток выиграет следующую гонку данных, или тем, какой мусор оказался по конкретному адресу памяти. Теперь у вас хайзенбаги и дыры в безопасности. Очень плохо.

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

Это делает Rust сложным, потому что вы не можете просто взять и сделать что-то! Вы должны узнать, как Rust это называет — найти нужный трейт или что-то ещё — и реализовать это так, как Rust ожидает. Но если вы это делаете, Rust может дать гарантии о поведении вашего кода, которые другие языки не дают, а это в зависимости от приложения может быть критично. Он также может давать гарантии о чужом коде, что делает использование библиотек в Rust простым и объясняет, почему проекты на Rust имеют почти столько же зависимостей, сколько проекты в экосистеме JavaScript.

Zig: свобода и контроль

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

Не знаю, правда ли это, но мне нравится думать о Zig как о реакции одновременно на Go и Rust. Go прост, потому что скрывает детали того, как работает компьютер. Rust безопасен, потому что заставляет прыгать через свои обручи. Zig освободит вас! В Zig вы контролируете вселенную, и никто не может указывать, что делать.

И в Go, и в Rust выделить объект в куче просто — достаточно вернуть указатель на структуру из функции. Выделение памяти неявное. В Zig вы выделяете каждый байт сами, явно. (В Zig ручное управление памятью.) У вас больше контроля, чем даже в C: чтобы выделить байты, нужно вызвать alloc() на конкретном виде аллокатора, то есть вы должны выбрать лучшую реализацию аллокатора для вашего случая.

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

Неопределённое поведение всё ещё важно в Zig

Zig называет его “нелегальным поведением” (illegal behavior). Он пытается обнаружить его во время выполнения и обрушить программу, когда это происходит. Для тех, кого беспокоит стоимость таких проверок по производительности, Zig предлагает четыре разных “режима релиза” на выбор при сборке программы. В некоторых проверки отключены. Идея в том, что вы можете запустить программу достаточно раз в проверяемых режимах, чтобы иметь разумную уверенность: в непроверяемой сборке нелегального поведения не будет. Это кажется мне очень прагматичным дизайном.

Ещё одно различие между Zig и двумя другими языками — отношение Zig к объектно-ориентированному программированию. ООП давно не в моде, и Go, и Rust избегают наследования классов. Но в Go и Rust достаточно поддержки других идиом ООП, чтобы вы могли построить программу как граф взаимодействующих объектов, если захотите. В Zig есть методы, но нет приватных полей структур и нет языковой возможности для полиморфизма во время выполнения (динамической диспетчеризации), хотя std.mem.Allocator просто умирает стать интерфейсом. Насколько я могу судить, эти исключения намеренны; Zig — язык для дата-ориентированного дизайна (data-oriented design).

Ещё одна вещь, которую я хочу сказать, потому что она открыла мне глаза: может показаться безумием создавать язык программирования с ручным управлением памятью в 2025 году, особенно когда Rust показал, что сборка мусора не нужна и компилятор может всё сделать за вас. Но это дизайнерский выбор, тесно связанный с выбором исключить возможности ООП. В Go, Rust и множестве других языков вы обычно выделяете маленькие кусочки памяти за раз для каждого объекта в графе объектов. У вашей программы тысячи маленьких скрытых malloc() и free(), и, следовательно, тысячи разных времён жизни. Это RAII. В Zig может показаться, что ручное управление памятью потребует много утомительной, подверженной ошибкам работы, но это так только если вы настаиваете на привязке выделений памяти к каждому маленькому объекту. Вместо этого вы можете просто выделять и освобождать большие куски памяти в определённых разумных точках программы (например, в начале каждой итерации цикла событий) и использовать эту память для данных, с которыми работаете. Именно этот подход и поощряет Zig.

Многие люди не понимают, зачем нужен Zig, если уже есть Rust. Дело не только в том, что Zig пытается быть проще. Думаю, разница более важная. Zig хочет, чтобы вы вырезали ещё больше объектно-ориентированного мышления из своего кода.

У Zig весёлая, подрывная атмосфера. Это язык для разрушения корпоративной классовой иерархии (объектов). Это язык для мегаломанов и анархистов. Мне он нравится. Надеюсь, он скоро выйдет в стабильный релиз, хотя текущий приоритет команды Zig — переписать все свои зависимости. Не исключено, что они попытаются переписать ядро Linux, прежде чем мы увидим Zig 1.0.

Go — для командной работы и быстрой разработки, Rust — для критически важных систем, где нужны максимальные гарантии, Zig — для тех, кто хочет полного контроля и готов от ООП отказаться в пользу дата-ориентированного подхода. Выбор зависит не от списка фич, а от того, какая философия вам ближе.

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

Почему это плохо

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

Это приводит к тому, что:

• невозможно использовать тип в интерфейсах других пакетов;
• ломается архитектура и DI (dependency injection);
• документация GoDoc не видит такие типы;
• код становится неидиоматичным и сбивает с толку других разработчиков.

Правильный подход

Правильный подход

Go поощряет простую инициализацию структур. Многие стандартные типы например,

работают корректно без конструктора. Для сложных сервисов используйте именованные конструкторы, которые проверяют зависимости и возвращают ошибку при некорректной инициализации. Это — идиоматичный путь Go: лучше обработать ошибку явно, чем скрывать её за “удобством”.

service, err := NewDomainService(cfg, deps)

if err != nil {

log.Fatal(err)

}

Итог

Экспортировать приватные типы — соблазнительно, но опасно. Это разрушает архитектуру и противоречит философии Go. Используйте приватные структуры только внутри пакета и придерживайтесь идиоматичных решений — они делают ваш код безопаснее и понятнее.

Источник статьи наш блог, опыт разработчика Webdelo

Cloudflare связала учащение «фатальных паник» на arm64 с кодом, где выполнялась работа с Netlink, но корневая причина оказалась глубже — в связанке компилятор ↔ ассемблер Go для arm64 и в том, как разбивалось большое смещение стека на две инструкции ADD со «сдвигом на 12 бит». Если прерывание попадало между этими двумя ADD, стековый указатель оказывался «наполовину скорректирован», и трассировщик стека считывал нерелевантные данные как адрес возврата, что заканчивалось segfault/фатальной паникой. Схожие аварии ранее отмечали и другие команды, в частности Datadog: именно в runtime.(*unwinder).next на Linux/arm64 (Go 1.23.x/1.24.x).

Что именно ломалось

• Сценарий сбоя: асинхронная предвыборка (preemption) попадает между двумя инструкциями корректировки SP (split ADD), после чего GC/трассировка начинают разворачивать некорректный фрейм, обращаясь по невалидному SP. Итог — падение в (*unwinder).next.
• Подтверждение на практике: сходные трассы стеков и «рандомные» крэши на arm64 фиксировались у сторонних команд; проблема оформлена в ишью #73259 в репозитории Go и была признана кандидатом на бэкпорт.

Как починили (и какие версии содержат фикс)

Исправление прошло через бэкпорт и доступно в поддерживаемых ветках Go:

• Go 1.24.6 — явное упоминание бэкпорта по ишью #73259.
• Go 1.23.12 — минор с правками рантайма (включая бэкпорт по связанным arm64-сбоям).
• Go 1.25.0 и новее — фиксация на мажорной ветке.

Суть изменения: вместо двух поочерёдных ADD для большого смещения теперь собирают оффсет в временный регистр и выполняют одну атомарную корректировку SP.

Это исключает «окно» между ADD-инструкциями и делает разворачивание стека предсказуемым даже при async preemption. (Подробные обсуждения и сопутствующие arm64-проблемы рантайма см. также в #63830, #65449, #73413.)

Кому это важно

• Все сервисы Go на arm64, где возможны большие стековые фреймы и активна асинхронная предвыборка (по умолчанию с Go 1.14+). В условиях продакшн-нагрузок редкая гонка становится статистически вероятной. Читайте подробнее: https://unskilled.blog/posts/preemption-in-go-an-introduction/

Что делать инженерам прямо сейчас

1. Обновиться до: Go 1.25.x или минимум до 1.24.6 / 1.23.12 (если «зажаты» веткой).
2. Пересобрать сервисы, критичные по доступности, и раскатить обновления в первую очередь на arm64-инфраструктуру.
3. Если апгрейд временно невозможен — минимизируйте большие стек-фреймы (вынос больших буферов в heap), снизьте вероятность попадания preemption в эпилог и проверьте зависимости на предмет собственного asm/unsafe-кода.
4. Отслеживайте релизы Go и связанные тикеты об unwinding/arm64 (см. #73259 и бекпорт #74694).

Источники и материалы:

• Обсуждение с примерами падений: runtime: segfaults in runtime.(*unwinder).next (GitHub, #73259).  https://github.com/golang/go/issues/73259
• Бэкпорт фикса в ветку 1.24: (GitHub, #74694) — релиз Go 1.24.6. https://github.com/golang/go/issues/74694
• История релизов, минор Go 1.23.12 с правками рантайма. https://go.dev/doc/devel/release
• Release notes Go 1.25 (фикс присутствует в мажорной ветке).  https://tip.golang.org/doc/go1.25
• Ранние разборы проблем разворачивания стека/прерываний на arm64 https://github.com/golang/go/issues/63830

Сборщик мусора Green Tea

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

Green Tea — это альтернативный алгоритм сборки мусора. Он настроен на борьбу с мелкими объектами. Пока что это экспериментальная функция, судьба Green Tea зависит от результатов тестирования сообществом.

Green Tea очищает последовательные блоки памяти (батчи). Размер блоков 8 КБ, в них хранятся объекты до 512 МБ. Объекты больше этого лимита обрабатываются по старому алгоритму.

Green Tea показывает впечатляющие результаты в тестах производительности. Например, 32-кратное ускорение маркировки в алгоритмах обхода графов. Green Tea GC эффективнее использует преимущества последовательного размещения данных в памяти.

В нагрузочных тестах с миллионом объектов Green Tea использовал на 22% меньше CPU, на 8% меньше потреблял память. Время выполнения тоже улучшилось на 5%.

Время пауз в основном остаётся коротким, но 99-й процентиль показал более длительные остановки — 1.84 мс против 0.92 мс у классического GC. То есть в редких случаях всё же могут возникать заметные задержки.

Пакет synctest

Ситуация: вы написали код с таймерами и хотите его протестировать. Паузы длятся по несколько секунд — совсем немного. Проблема в том, что у нас 100 тестов, т. е. одна итерация тестирования займёт несколько минут.

До synctest у вас было на выбор четыре сценария:

• пропускать тесты,
• ждать все таймауты,
• создавать интерфейсы-обёртки,
• передавать функции времени как параметры.

В Golang 1.25 можно сделать проще — обернуть тест в synctest.Run() и пропустить время ожидания.

Как работает synctest

Функция подменяет системное время. Например, когда код вызывает time.Sleep(5 * time.Second), виртуальные часы переводятся на 5 секунд вперёд, и выполнение теста мгновенно продолжается.

Ограничения

Synctest работает только со стандартными функциями. Подменять системное время бесполезно, если ваш код обращается, например, к PostgreSQL, или читает timestamp из файла.

Пакет encoding/json/v2

Разработчики Golang не стали изменять существующий пакет, чтобы сохранить обратную совместимость. Вместо этого добавили вторую версию пакета — encoding/json/v2.

По скорости новая версия сравнима с внешними библиотеками вроде jsoniter. При декодировании v2 быстрее предыдущей версии в 3-10 раз. Ещё json/v2 в 38,6 раза быстрее читает JSON.

Прямая работа с Reader и Writer

Функции MarshalWrite и UnmarshalRead работают напрямую с io.Writer и io.Reader. Они экономят память при обработке большого JSON, т. к. не создаются промежуточные байтовые буферы Encoder и Decoder.

Настройки прямо при вызове

В encoding/json/v2 можно передавать опции прямо в функции маршалинга.

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

Новые теги для структур

• inline встраивает поля вложенной структуры на уровень родителя — больше не нужно дублировать поля адреса в структуре пользователя.
• case строго сопоставляет имена полей при парсинге JSON — с настройкой «ignore» программа будет считать одинаковыми userName, user_name и UserName. С настройкой «strict» потребует точного совпадения регистра и символов.
• unknown собирает все неизвестные поля в одну map — удобно для работы с динамическими API, где набор полей может меняться.
• format указывает формат для времени, дат и других типов прямо в структуре.

Кастомные преобразователи без изменения типов

В Go 1.24 для кастомной логики сериализации приходилось создавать новый тип и реализовывать Marshaler/Unmarshaler. Теперь можно написать функцию-преобразователь через MarshalFunc и использовать её только там, где нужно.

Изменения в поведении по умолчанию

encoding/json/v2 может сломать существующий код:

• Nil-слайсы теперь кодируются как пустые массивы [] вместо null, nil-карты — как пустые объекты {} вместо null.
• Байтовые массивы автоматически кодируются в base64-строки, а не в массивы чисел.
• При декодировании имена полей сравниваются с учётом регистра — поле «name» в JSON не найдёт поле Name в структуре.

Улучшена потоковая обработка

Добавили функции UnmarshalDecode и MarshalEncode для работы с большими JSON-файлами, где данные идут потоком (логи, экспорты БД). Они работают с jsontext.Decoder и jsontext.Encoder, обрабатывая по одному JSON-объекту за раз без загрузки файла в память.

Композиция настроек и маршалеров

Опции и маршалеры объединяются через JoinOptions и JoinMarshalers. Т. е. можно создавать переиспользуемые наборы настроек для разных сценариев.

Например, один набор для внешнего API с красивым форматированием, другой для внутренних сервисов с компактным выводом.

Метод WaitGroup.Go

Добавили новый метод Go(), чтобы упростить работу с горутинами. Изменение небольшое, но очень полезное — ваш код в версии 1.25 станет чище и безопаснее.

Метод упаковывает часто используемый код в удобную функцию. WaitGroup.Go() автоматически вызывает wg.Add(1), запускает переданную функцию в новой горутине и добавляет defer wg.Done() в начало выполнения функции.

Work Pattern для go.work

Представьте, что у вас есть большой проект с множеством микросервисов: сервис A, сервис B, сервис C и так далее. Раньше, чтобы запустить тесты во всех сервисах, приходилось писать длинные команды, явно указывая каждый модуль:

В Go 1.25 можно просто написать:

И тесты запустятся автоматически во всех модулях, указанных в файле go.work.

Трассировка runtime/trace.FlightRecorder

Трейсинг в Go — это дорогое удовольствие. Обычное трассирование записывает всё подряд с самого начала до конца программы. Flight Recorder работает по-другому:

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

FlightRecorder вызовы функций, активность горутин, время выполнения операций, использование памяти, работу сборщика мусора.

Группировка атрибутов в slog

За группировку атрибутов отвечает метод slog.Group(). Он принимает второй параметр типа []any, куда можно передать абсолютно любые данные — строки, числа, объекты. Проблема в том, что компилятор не знает, действительно ли вы передаёте корректные атрибуты для логирования.

В Go 1.25 появился метод groupAttrs, который принимает строго типизированный слайс атрибутов []slog.Attr. В этом случае компилятор сможет проверить корректность данных на этапе компиляции.

Если попытаетесь добавить в слайс что-то кроме slog.Attr, получите ошибку компиляции.

GOMAXPROCS учитывает запуск в контейнерах

Эта переменная окружения определяет максимальное количество потоков ОС для одновременного выполнения горутин. По умолчанию GOMAXPROCS равняется количеству логических процессоров на машине.

Например, ваше приложение запущено в Docker-контейнере с ограничением 2 CPU на сервере с 16 ядрами. В старых версиях Go пытается использовать все 16 ядер. Чтобы приложение соблюдало ограничения, разработчики вынужденно ставили стороннюю библиотеку automaxprocs.

В новой версии Go автоматически:

1. Читает настройки cgroups.
2. Определяет доступное количество CPU для контейнера.
3. Устанавливает GOMAXPROCS в соответствии с этими ограничениями.

Если контейнер ограничен 2 CPU, Go автоматически установит GOMAXPROCS=2, независимо от количества ядер у физического сервера.

Исправление бага в компиляторе Go 1.21+

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

Например, вы открываете файл и сразу пытаетесь с ним работать. По логике Go, если файл не открылся, вы должны получить панику при попытке обратиться к nil-указателю:

В Go 1.21-1.24 компилятор «оптимизировал» код, переставляя строку name = f.Name() после проверки ошибки. Поэтому программа завершалась без паники.

В Go 1.25 компилятор выдаёт «invalid memory address or nil pointer dereference», как и должно быть.

Ждёте стабильную версию GC Green Tea в Golang 1.26? Расскажите в комментариях, как новый сборщик показал себя на реальных рабочих нагрузках — другим разработчикам будет интересно почитать про ваш опыт.

Давайте разберёмся, корректно ли сравнивать эти языки, посмотрим на плюсы, минусы технологий и выясним, в каких сценариях раскрываются их сильные стороны.

Комментарии по теме предоставили: разработчики Василий Зорин, Эдуард Дыкман; автор курсов в Яндекс Практикуме Кирилл Федченко; участники сообщества Golang Go и Rust.

⚠️ Мы не ищем язык-убийцу. В публикации собрали популярные мнения, чтобы помочь в принятии взвешенного решения для ваших проектов.

Почему Go и Rust считают конкурентами, если они такие разные?

Первый со сборщиком мусора больше похож на Java. Второй без сборки мусора, и напоминает продвинутый C++. Но постойте!

Во-первых, языки появились практически одновременно. Go заявил о себе в 2009 году, Rust показали в 2010-м. «Современный язык для разработки быстрых и безопасных приложений», — так говорили про Go, так говорили про Rust.

Во-вторых, несмотря на разные подходы к управлению памятью, оба языка метят в одну и ту же аудиторию. К ним приходят разработчики, которым нужно быстрее Python, но безопаснее C++.

В-третьих, на этих языках пишут схожие типы приложений: веб-серверы, микросервисы, CLI-инструменты и системное ПО. Например, на Go написаны Docker и Kubernetes, а на Rust — Firecracker (AWS), движок Servo, Vector.

Оба языка конкурируют в backend-разработке, облачных вычислениях и инструментах DevOps, где ключевыми являются масштабируемость и параллелизм. Например, в области:

— микросервисов: оба языка используются для создания распределенных систем, при этом функции безопасности Rust могут быть предпочтительнее для критически важных компонентов;
— сетевого взаимодействия: такие инструменты, как gRPC или HTTP-серверы, реализованы в обоих языках;
— облачной инфраструктуры: компании используют Go из-за его простоты, а Rust для компонентов, критически важных для производительности.

Rust лучше подходит для системного программирования (компиляторы, драйверы, ОС), в то время как Go более распространен в крупномасштабных сервисах высокой доступности, где приоритетна быстрая разработка.

Простота сейчас или надёжность потом?

Go следует принципу «простота превыше всего»: минимум синтаксического сахара, встроенная поддержка горутин, автоматическая сборка мусора.

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

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

У Rust другая философия — «лучше потратить время на борьбу с компилятором сейчас, чем часы на отладку багов потом».

Система типов и borrow checker заставляют контролировать жизненный цикл данных, помнить про безопасность потоков и обработку ошибок ещё до запуска программы. Компилятор не позволит собрать код с потенциальными проблемами.

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

Что привлекает в Rust — это инструментарий и экосистема. Язык развивается предсказуемо: стабильные обновления выходят по календарю, есть понятная схема nightly → beta → stable.

Из минусов — интеграция с другими языками требует дополнительных усилий по настройке FFI, но решения для этого есть (#[repr(C)]). Возникают вопросы к архитектуре: например, async/await добавили раньше, чем проработали корутины, и теперь приходится подгонять одно под другое не самыми элегантными методами. Ещё Rust компилируется заметно дольше других языков.

Сколько нужно времени на обучение Rust и Go?

Golang с нуля можно освоить за 2-4 недели. Документация Go содержит исчерпывающую информацию о синтаксисе, стандартной библиотеке и концепциях программирования. Больше всего времени потребуется на изучение горутин, каналов, системы интерфейсов.

Документация Rust не менее подробная. Синтаксис языка сложнее. Обучение затягивается из-за уникальной системы владения памятью (ownership) и концепции времени жизни (lifetimes). Ещё нужно время на принятие borrow checker, когда кажется, что компилятор специально мешает писать код.

Borrow checker — лучший друг программиста, он следит за соблюдением модели владения. Основное правило гласит, что в любой момент времени на переменную может ссылаться либо одна мутабельная ссылка (с правом записи), либо сколько угодно иммутабельных (только чтение). Это нужно соблюдать в любом языке, который поддерживает многопоточность. В Golang, например, с data races приходится бороться своими силами. Также borrow checker убеждается в отсутствии «висячих» указателей (когда ссылка живёт дольше, чем данные).

Входной порог может быть высоким: освоить владение и заимствование, особенности синтаксиса и обработки ошибок бывает непросто не только новичкам, но и опытным разработчикам. Существуют курсы, помогающие плавно перенастроить профессиональный стек под другой язык, например, «Rust для действующих разработчиков» в Яндекс Практикуме помогает быстро перейти к практике.

Вы знали, что код на Rust в 2,6 раза проще кода на Go?

В июне 2025 года TIOBE проанализировало 1,5 миллиарда строк кода, измеряли сложность программ на разных ЯП. Считали количество путей выполнения в функциях — чем меньше число, тем проще код для понимания и поддержки.

Как получилось, что Golang в 2,6 раза сложнее Rust?

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

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

Большое преимущество Go — это низкий порог входа (25 ключевых слов против 70 в Rust). Стандартная библиотека довольно небольшая, но в ней есть практически всё. По моему опыту, в средней кодовой базе на Golang разобраться больше шансов, чем в Rust.

Когда Rust работает быстрее Go, и где это используют?

Представим интернет-магазин: пользователь заходит на страницу товара, сервер идёт в базу данных и отдаёт JSON. В таких случаях Go и Rust работают примерно одинаково быстро — узкое место в скорости ответов БД.

Теперь вы обрабатываете видео в реальном времени или анализируете миллионы финансовых транзакций. В этом случае предпочтительнее Rust, и вот почему.

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

В Golang накапливается «мусор», который в какой-то момент будет обработан сборщиком, что по времени может совпасть с внешней полезной нагрузкой и ухудшить время отклика сервера.

В Rust память удаляется автоматически, как только её владелец выходит из области видимости. Так что любые приложения, в которых важным аспектом производительности является управление памятью, могут выиграть за счёт использования Rust (БД, ОС, браузеры, видеоигры).

Rust приносит реальную пользу в продакшене там, где простои и уязвимости стоят дорого:

— встроенные системы (устройства IoT, ПО для автомобилей) — безопасность и эффективность Rust снижают вероятность сбоев оборудования, от которого зависят жизни людей.
— финансовые услуги — высокочастотные торговые платформы, использующие Rust, могут обрабатывать транзакции быстрее и с меньшим количеством ошибок, что повышает конкурентоспособность.
— облачная инфраструктура — высокая производительность и минимализм Rust в области сетевого взаимодействия и параллелизма (например, в Tokio) позволяют снизить затраты на сервер, что напрямую влияет на размер прибыли

Параллельная обработка

Допустим, вам нужно скачать 3000 файлов. В Go можно написать цикл с горутинами — синтаксис интуитивно понятный, и базовый вариант заработает без глубокого изучения теории.

В случае с Rust придётся почитать про async/await, разобраться с библиотекой Tokio, понять разницу между async fn и обычными функциями. Зато получите полный контроль над тем, как именно выполняется код.

Потребление ресурсов

Go жирнее по памяти. Каждая горутина занимает от 2 КБ, плюс сборщик мусора держит в памяти объекты про запас. Для веб-сервиса не критично, для встраиваемых систем может стать проблемой.

Rust экономнее — вы платите только за то, что реально используете. Программу на Rust можно запустить на микроконтроллере с 32 КБ памяти. Go туда не поместится.

В чём разница между развертыванием Go и Rust приложений?

Оба языка компилируются в один исполняемый файл — просто скопировали на сервер и запустили. Docker-образы получаются крошечными, особенно у Rust (можно упаковать в scratch-образ размером несколько мегабайт). Go чуть проще интегрируется с существующей инфраструктурой.

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

В каких сферах Go и Rust делят рынок программирования?

Go

• Идеален для микросервисов и REST API. Фреймворки Gin и Echo помогают быстро собрать рабочий сервис — например, для регистрации пользователей или каталога товаров.
• Docker, Kubernetes, Terraform — все написаны на Go. Язык используют для консольных приложений: получается один файл, который запускается везде без дополнительных зависимостей.
• В больших командах с частой сменой разработчиков Go встречается чаще. Простой синтаксис означает, что новые разработчики быстрее разбираются в коде проекта.

Rust

• Операционные системы, драйверы — области, где Rust конкурирует с C++. Язык предлагает сопоставимую производительность, но защищает от ошибок с памятью.
• Rust компилируется в эффективный WebAssembly для запуска вычислений в браузере. Используется в играх, обработке изображений, криптографии.
• Ripgrep (аналог grep) и exa (аналог ls) демонстрируют возможности Rust — они работают быстрее классических Unix-утилит.
  

Rust лучше подходит для системного программирования (компиляторы, драйверы, ОС), в то время как Go более распространен в крупномасштабных сервисах высокой доступности, где приоритетна быстрая разработка

Стоит ли изучать Rust, если более простой Go справляется с большинством задач?

Всё зависит от ваших целей. Кирилл Федченко отмечает:

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

— Rust стоит изучить, если вам нужен максимальный контроль над производительностью, безопасностью или низкоуровневыми сущностями (операционные системы, встраиваемые системы). Если ваша цель — создание высокопроизводительных, критически важных систем, то инвестиция времени в изучение Rust один из эффективных способов.

Go часто достаточно для решения задач, но более широкое применение и растущий спрос на Rust делают его ценным навыком для карьеры. Уже восемь лет подряд язык признается лучшим в опросе Stack Overflow, а его сообщество растет быстрее, чем у других языков. Именно поэтому многие переучиваются на Rust с Go, C++ или Python, особенно при переходе в системное программирование или области, где безопасность имеет ключевое значение.

Почему Rust не вытеснит Go, несмотря на все преимущества?

Rust не заменит язык Go, потому что последний хорошо решает свои задачи.

Golang и Rust используют для разных целей. Сценариев применения Rust меньше, чем для Go. Поэтому Golang популярнее, но это не замена Rust.

Оба языка далеки от идеала для написания бизнес-логики, она теряется за синтаксическими конструкциями. В зависимости от области, для бизнес-логики я бы предложил рассмотреть typescript, java/kotlin, elixir, clojure.

Комментарии открыты: в каких проектах вы наблюдали, как неправильный выбор языка негативно отразился на продукте?

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

Что умеет PromptLock

По данным ESET, PromptLock:

• написан на языке Golang, с версиями для Windows и Linux;
• использует ИИ-модель gpt-oss-20b через локальный API Ollama;
• генерирует вредоносные Lua-скрипты на лету, которые сканируют файловую систему, выбирают цели для атаки, шифруют и похищают данные;
• потенциально способен уничтожать данные, но эта функция пока не реализована.

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

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

Зачем в вирусе нужен ИИ

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

Именно такие примеры показывают, как ИИ может автоматизировать все этапы атаки — от разведки до кражи данных. Подобные инструменты меняют масштаб и скорость атак

Почему это тревожный сигнал

Хотя PromptLock пока выглядит как прототип или доказательство концепции, его появление сигнализирует об одном: инструменты на базе ИИ становятся доступными не только бизнесу, но и киберпреступникам.

Теперь для создания продвинутого вредоносного ПО не обязательно быть опытным программистом — достаточно задать правильный промпт. Сама угроза особенно актуальна в контексте:

• распространения локальных моделей и open-source решений;
• снижения технического порога входа для атакующих;
• роста интереса APT-групп к ИИ-автоматизации атак.

Что делать

Эксперты рекомендуют:

• пересмотреть защиту ИТ-инфраструктуры от динамически генерируемых скриптов;
• уделить внимание аномалиям в поведении программ, а не только сигнатурам;
• следить за новыми классами угроз с участием ИИ.

Одно из главных новшеств — container-aware GOMAXPROCS: теперь по умолчанию значение GOMAXPROCS учитывает лимиты CPU в cgroup.

На Linux это позволит процессам внутри контейнеров (например, в Kubernetes) автоматически адаптировать использование процессорных ресурсов к выделенной квоте.

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

Новый сборщик мусора — до 40% быстрее

В экспериментальном режиме появился garbage collector нового поколения с улучшенной локальностью и масштабируемостью.

Он особенно эффективен в приложениях с большим количеством мелких объектов, снижая накладные расходы на GC на 10–40%. Включается через GOEXPERIMENT=greenteagc.

Trace Flight Recorder: отладка по горячим следам

Введен runtime/trace.FlightRecorder — «черный ящик» для приложений на Go.

Он постоянно пишет трейс в кольцевой буфер, позволяя при наступлении события выгрузить последние секунды исполнения в файл.

Нововведение значительно упрощает отладку редких и трудно воспроизводимых багов.

Другие изменения в рантайме и инструментах

• Исправлена ошибка компилятора с отложенной проверкой nil, из-за которой некорректный код мог выполняться без паники.
• Добавлена поддержка DWARF5 — меньше отладочной информации и быстрее линковка.
• Улучшено выделение памяти для слайсов — быстрее в ряде сценариев.
• В Linux теперь можно видеть имена анонимных VMA ([anon: Go: heap]) в отладочных инструментах ядра.
• Новый пакет testing/synctest для тестирования конкурентного кода с виртуальным временем.
• Экспериментальный пакет encoding/json/v2 с ускоренным парсингом и расширенной конфигурацией маршалера.
• Новый метод WaitGroup.Go для удобного запуска горутин с учетом синхронизации.

Платформенные изменения

Go 1.25 требует macOS 12 и выше. 32-битная Windows/ARM-платформа будет удалена в следующем релизе.

На RISC-V появился режим сборки плагинов и поддержка профиля RVA23U64.

Заметили, что массового внедрения не произошло? Разработчики не спешат переписывать рабочий код на дженериках.

По каким причинам обобщённые типы оказались невостребованными? — ответим на этот вопрос вместе с участниками тг-канала Golang GO.

Почему дженерики не вытеснили интерфейсы?

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

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

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

Наиболее оправданный случай использования дженериков — замена interface{} в местах, где тип известен на этапе компиляции:

Когда всё-таки использовать дженерики?

Практика показывает, что обобщённые типы нашли применение в конкретных областях.

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

1. Пулы соединений и кэширование

Наиболее очевидное применение дженериков — создание типизированных контейнеров.

Например, этот пул соединений будет работать с любым типом ресурсов, поддерживающих закрытие:

Аналогично с кэшированием. Можно создавать строго типизированный кэш, который возвращает значения правильного типа на этапе компиляции:

2. Математические операции

Дженерики избавляют от дублирования кода для разных числовых типов:

3. Функции высшего порядка

С появлением дженериков появилась возможность создавать типобезопасные функции высшего порядка для работы с коллекциями:

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

4. Обёртки для API и протоколов

Так выглядит обёртка ответа с типизированным полем результата на дженериках:

Компилятор гарантирует соответствие типов на этапе компиляции. До дженериков приходилось использовать json.RawMessage и распаковывать на уровне роутинга.

5. Репозитории и CRUD-операции

Типизированные интерфейсы для работы с данными:

Как дженерики повлияли на тесты?

Однозначно стало проще создавать универсальных хелперов для тестирования:

Почему дженерики в Go не такие, как в других языках?

Отсутствие обобщённых типов болезненно воспринимали разработчики, перешедшие в Go из Java, C#, C++ и других языков с дженериками.

Добавление функционального программирования — это тренд Rust, Kotlin и других современных языков. Без дженериков в Go было бы сложно переписывать код в функциональной парадигме с других языков.

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

Например, это работает:

А такая функция уже не скомпилируется:

Привычные паттерны из Rust, Java или C# в Go просто не реализуемы. Вместо методов приходится использовать функции:

Как дженерики изменили разработку на Go?

Типовые задачи в Го до появления дженериков решали иначе. Приходилось использовать пустой interface{}, генерировать типобезопасный код с помощью go:generate, stringer.

Несмотря на недостатки, дженерики поменяли подход к разработке.

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

Обобщённые типы активно используются в библиотеках. Взять тот же samber/lo и функции Map, Filter, Reduce на дженериках. Ещё стандартная библиотека пополнилась пакетами slices и maps.

Что касается производительности — ожидания не оправдались. Думали, что избавились от преобразований типов и получили прирост скорости? На деле разница минимальна. В реальных приложениях узкое место не в типах, а в работе БД, сетевых запросах или бизнес-логике.

Что в итоге?

• Интерфейсы остаются основой архитектуры Go-приложений, дженерики их дополняют, но не заменяют.
• Обобщённые типы полезны только для конкретных задач. Применяйте по необходимости, когда дженерики устраняют дублирование кода или повышают типобезопасность.
• Упрощайте тестирование — универсальные хелперы для проверок и утверждений.
  
• Избегайте преждевременного обобщения — не пишите код через дженерики «на всякий случай».
• Параметры типов лучше всего подходят для контейнеров, кэшей, математических функций.
• Привычные паттерны из других языков не реализуемы — приходится адаптировать подходы под Go.
• Усложнение понимания кода — иногда непросто разобраться, что происходит с конкретной сущностью.

Поделитесь опытом использования дженериков — где они реально помогли, а где оказались излишними? Удивите примерами удачного и неудачного применения!

В этой подборке — 7 курсов, после которых реально получить первую работу в IT за 3–6 месяцев.

Почему в 2025 попасть в IT и легче, и сложнее одновременно

Войти в IT в 2025 реально, но рынок сильно изменился. С одной стороны, спрос на junior-специалистов вернулся: компании снова набирают новичков, открывают стажировки и гибридные программы. Но конкуренция стала выше, а фильтры — жёстче.

Что легче

• После карьерного спада 2022–2023 спрос на junior-специалистов начал восстанавливаться. Появилось больше стажировок и вакансий для начинающих. Согласно отчёту Robert Half, начать успешную карьеру могут инженеры по данным, DevOps-инженеры и разработчики ПО. Однако конкуренция остаётся высокой, и работодатели ожидают от кандидатов не только базовых знаний, но и быстрой адаптации к новым инструментам.
• Образование и работа в IT всё чаще переходят в гибридный формат: можно совмещать онлайн- и офлайн-обучение, работать удалённо и периодически встречаться в офисе.

Что сложнее

• Конкуренция выше, чем раньше. Даже на стартовые позиции часто подаётся по сотне кандидатов.
• Работодатели ждут не просто знаний или диплома, а быстрой адаптации.

Что изменилось в 2025 по сравнению с 2020–2024

Во-первых, образование стало прагматичнее. С 2020 по 2022 год рынок был наводнен короткими курсами «на джуна». В 2025-м большинство таких школ либо закрылись, либо переформатировались: люди устали платить за теорию без практики. Сейчас ценятся программы, в которых есть командные проекты, ревью от наставников, работа с Git и проектный пайплайн, близкий к реальному.

Во-вторых, работодатели всё чаще оценивают кандидатов по их реальным навыкам и опыту, а не по формальному образованию. Согласно прогнозам, 39% текущих навыков работников устареют к 2030 году, что подчеркивает необходимость постоянного обновления и адаптации.

Так, расширяются границы образования. А вместе с ними – появляются онлайн-курсы.

7 курсов, с которых начинают карьеру в IT

1. Kata Academy — GO-разработчик

Ссылка на курс

Go (Golang) — это билет в backend-разработку, где в 2025 году крутятся большие деньги и хардовые задачи. Язык, созданный Google, ценят за скорость и простоту, а компании от стартапов до гигантов вроде Яндекса выстраиваются в очередь за Go-разработчиками. Курс от Kata Academy учит писать серверный код, работать с SQL, Git, Linux и Docker, чтобы выпускники могли строить масштабируемые приложения.

📚Что получают выпускники

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

• Есть карьерная поддержка: резюме, собеседования, вакансии;
• В договоре — гарантированная зарплата от 120 000 ₽ (может быть выше).

🎓Длительность и формат

Курс проводится полностью онлайн. Длительность обучения — 9 месяцев, включая подготовку к собеседованиям. Нагрузка: от 25 часов обучения в неделю (3-4 часа в день), есть дедлайны. Выпускник устраивается на работу после курса, в течение 1-2 месяцев (в среднем).

👥Кому подойдет

• Новичкам без опыта в программировании;
• Студентам и начинающим разработчикам, которые хотят освоить Go;
• Может быть интересен тем, кто работает во фронтенде или техподдержке и хочет сменить направление.

Не требует знаний математики и программирования — рассчитан на обучение с нуля.

🏆Возможности после курса

На сайте указано, что выпускники устраиваются в компании, такие как Яндекс, Альфа-Банк и Kaspersky, часто в течение первого месяца после завершения основной программы курса. Если выпускник не найдет работу с зарплатой от 120.000 рублей, то оплачивать обучение не придется.

💸 Стоимость и условия участия

Есть два варианта обучения:

• Интенсивное (стоимость — 110 000 рублей во время учебы плюс 20% от зарплаты в первый год работы). Для тех, кто живет в Москве или Санкт-Петербурге, или готов туда переехать.
• Асинхронное (стоимость — 262 000 рублей). Обучение в своем темпе, нет дедлайнов. Можно искать работу в любом городе-миллионнике, если не получится устроиться — есть гарантия возврата денег.

2. CyberEd — Пентестер

Ссылка на курс

Пентест (тестирование на проникновение) — это процесс поиска уязвимостей в IT-системах путем имитации атак хакеров.

Курс обучает анализу защищенности веб-приложений, сетей и инфраструктуры, а также использованию инструментов вроде Nessus и Nmap.

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

📚Что получают выпускники

• Выпускники получают диплом о профессиональной переподготовке или удостоверение о повышении квалификации (зависит от формата).
• Студенты формируют цифровое резюме и портфолио на основе практических заданий.
• Все студенты проходят карьерную подготовку — от тренировки прохождения собеседований до подбора стажировок и вакансий.

🎓Длительность и формат

Обучение длится 24 недели (365 академических часов) и проходит полностью онлайн. Есть два формата:

• Синхронный формат — с расписанием и онлайн-занятиями в группе. Включает 24 онлайн-семинара по 4 часа, регулярную обратную связь от наставников и карьерные консультации.
• Асинхронный формат — без привязки ко времени: обучение проходит в удобном для студента темпе. Доступ ко всем материалам курса, заданиям и модулям открыт сразу.

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

👥Кому подойдет

• Айтишникам, которые хотят научиться пентесту или прокачаться в кибербезопасности.
• Системным администраторам, веб-разработчикам, специалистам по ИБ, а также джунам и миддлам из пентеста, Blue Team или AppSec.

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

🏆Возможности стажировки и трудоустройства

Выпускники устраиваются на позиции инженеров по безопасности или пентестеров, в том числе в крупные IT-компании. По отзывам студентов, некоторые находят стажировку уже на 4 месяц обучения, а часть получает постоянные позиции в течение 1 года после финала курса.

💸 Стоимость и условия участия

138 000 рублей за синхронный формат, 74 000 рублей за асинхронный. Доступна рассрочка на 2 года — 6 900 рублей в месяц.

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

3. Яндекс Практикум — Инженер по тестированию

Ссылка на курс

Инженер по тестированию (QA-инженер) проверяет качество программных продуктов: ищет ошибки в веб-приложениях, мобильных приложениях и API.

В программе курса Яндекс Практикума будут основы ручного тестирования, работа с тестовой документацией и инструментами, базовые навыки автоматизации, а также отдельные модули по информационной безопасности, Figma, Python и SQL.

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

📚Что получают выпускники

• В финале курса Практикум выдаёт диплом о профессиональной переподготовке.
• Также у выпускников остаётся портфолио из 7 учебных проектов (в расширенной версии курса — из 9). Среди них, например, — итоговая работа над сервисом Яндекса (тестирование Яндекс.Маршрутов и т.д.).
• Дополнительно открывается доступ к модулю по YandexGPT и YandexART.
• В течение семи месяцев после окончания обучения доступна карьерная поддержка. При желании можно набираться опыта в Мастерской Практикума — это агентство внутри Практикума, где выпускники работают над задачами реальных заказчиков.

🎓Длительность и формат

• Курс рассчитан на пять месяцев — это 318 академических часов, в среднем около 20 часов в неделю. Обучение проходит онлайн.
• Теоретическая часть будет в виде интерактивного учебника, а практические задачи выполняются по спринтам: каждые три недели — новый проект.
• Воркшопы и консультации с наставниками проходят по расписанию. У студентов есть дедлайны по проектным заданиям.

👥Кому подойдет

• Новичкам без опыта в IT — студентам, тем, кто хочет сменить профессию, и специалистам из смежных областей.
• Техническое образование и навыки программирования не требуются, но базовый английский будет плюсом, особенно если планируете развиваться в сторону автоматизации.

🏆Возможности стажировки и трудоустройства

После завершения программы карьерный центр помогает в трудоустройстве (доступны карьерная поддержка в течение 6+ месяцев после обучения, фриланс-трек для тех, кто хочет работать на себя, вакансии и стажировки от партнёров и мастерская проектов). В среднем, стажёры зарабатывают около 52 000 рублей, джуниоры — 76 000, мидлы — 142 000 рублей.

💸 Стоимость и условия участия

• Junior-трек. Подходит для старта в тестировании. 77 000 ₽ — при полной оплате; 16 500 ₽/мес. × 5 месяцев — при рассрочке.
• Расширенный трек. Тут больше практики и навыков, чтобы быстрее вырасти до мидла. 148 000 ₽ — при полной оплате; 18 500 ₽/мес. × 9 месяцев — при рассрочке.
• От новичка до автоматизатора. Сразу две профессии: ручное и автоматизированное тестирование. 156 000 ₽ — при полной оплате. 20 000 ₽/мес. × 9 месяцев — при рассрочке.

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

4. Rebrain — Мини-практикум Golang с нуля

Ссылка на курс

Мини-практикум от Rebrain знакомит с основами Go, включая синтаксис, работу с каналами, контекстами и микросервисами. Программа ориентирована на практическое освоение языка через выполнение задач, моделирующих реальные сценарии backend-разработки.

📚Что получают выпускники

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

Доступ к комьюнити и онлайн-мероприятиям Rebrain позволяет продолжать обучение и налаживать профессиональные связи. Теоретические материалы остаются доступными навсегда.

🎓Длительность и формат

• Курс длится около 2 недель, но продолжительность зависит от темпа студента.
• Программа полностью онлайн и асинхронная, что позволяет учиться в удобное время без привязки к расписанию.
• Формат текстовый, без видеолекций, с акцентом на практику (90% времени).

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

👥Кому подойдет

• Студентам с потенциалом для Go;
• Начинающим разработчикам без практического опыта;
• Специалистам из смежных IT-направлений.

Здесь нужны минимальные навыки работы с системами контроля версий (GitHub/GitLab), но глубокие знания программирования не требуются.

🏆Возможности стажировки и трудоустройства

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

💸 Стоимость и условия участия

Стоимость курса — 14 990 рублей при полной оплате или 1 249 рублей в месяц при рассрочке на 12 месяцев. Для поступления достаточно подать заявку через сайт; специальных требований, кроме базового понимания IT, нет. Курс подходит для самостоятельного обучения, но требует дисциплины из-за асинхронного формата.

5. Systems.Education — Системный аналитик / Проектировщик корпоративных информационных систем

Ссылка на курс

Цель программы — получить профессию системного аналитика, которая соответствует актуальным требованиям вакансий на рынке.

На курсе от Systems.Education вы за 3 месяца пройдёте реальный кейс за счёт работы с:

• Формальным моделированием бизнеса и бизнес-проблемы: Event Storming, BPMN, Opportunity canvas.
• Разработкой пользовательских требований: Impact map, User story map, Use case diagram, Use case scenario.
• Концептуальным проектированием ИТ-решений: моделирование предметной области, UML диаграмма состояний, Контекстная диаграмма, Концептуальная модель данных, Макеты приложений.
• Спецификацией требований к системе: Функциональные требования к системе, Нефункциональные требования к системе, Требования к информационной безопасности, Системные алгоритмы.
• Техническим проектированием ИТ-решений: Диаграмма взаимосвязи объектов, диаграммы в нотации С4, Требования к интеграции, UML диаграмма последовательности, Data flow diagram.

📚Что получают выпускники

• Сертификат на основании лицензии об образовательной деятельности, подтверждающий квалификацию системного аналитика уровней 4 и 5 по российскому профстандарту.
• Портфолио, включающее результаты их учебного проекта.
• Демонстрацию финальных результатов кейса перед приглашенными HR и техническими специалистами из компаний-потенциальных работодателей.

🎓Длительность и формат

Курс длится 3 месяца (200+ академических часов) и проводится полностью онлайн: 8 часов в неделю — занятия с преподавателем в Zoom, дополнительно — командные и индивидуальные созвоны с ментором. Процесс обучения осуществляется в командах, в которых участники работают над реальным кейсом.

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

👥Кому подойдет

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

🏆Возможности стажировки и трудоустройства

• Защитите итоговый проект прямо перед HR и техспецами из компаний.
• Получите портфолио из настоящих проектных документов (артефактов) — всё, что требуют работодатели на позиции младшего системного аналитика.
• В течение всего обучения вас будут сопровождать менторы-практики: помогут с проектом, дадут фидбек, подготовят к собеседованиям.

По статистике школы, выпускники за год могут дорасти до уровня Middle-аналитика.

💸 Стоимость и условия участия

• 205 000 рублей для физических лиц
• 255 000 рублей для юридических лиц.

Действует скидка на раннее бронирование. Потоки стартуют раз в три месяца. Для поступления требуется подать заявку через сайт. Базовые знания IT-процессов желательны, но специальных тестов нет. Гарантируется 100% возврат средств при отказе до начала обучения.

6. Karpov.Courses — Аналитик данных

Ссылка на курс

Курс от karpov.courses учит работать с Python, SQL, Power BI и другими нужными инструментами для анализа, визуализации и автоматизации. В программе много практики: решаете реальные задачи — A/B-тесты, расчёт метрик, анализ больших данных, работа с хранилищами.

📚Что получают выпускники

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

Материалы курса остаются доступны бессрочно.

🎓Длительность и формат

Курс длится 5 месяцев и проводится полностью онлайн на LMS-платформе. Студенты проходят уроки и выполняют домашние задания в удобном темпе, с ежедневной поддержкой кураторов и экспертов.

👥Кому подойдет

• Новичкам без опыта в IT, студентам, чтобы освоить аналитику данных.
• Маркетологам и менеджерам, чтобы рассчитывать метрики бизнеса и их эффективность.
• Специалистам с релевантным опытом (джуниорам и выше).

Базовые навыки работы с данными (например, Excel или SQL) полезны, но не обязательны.

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

🏆Возможности стажировки и трудоустройства

Karpov.Courses предлагает карьерную поддержку по поиску работы, чат с консультантами и доступ к вакансиям от партнеров.

Выпускники могут стать младшими аналитиками данных или Data Scientist с медианной зарплатой на старте 100–120 000 рублей, а если уровень мидл — от 180 000 рублей. По данным школы, 3 месяца — средний срок успешного трудоустройства.

💸 Стоимость и условия участия

Стоимость базового тарифа — 80 000 рублей при единовременной оплате. Доступна беспроцентная рассрочка на 24 месяца (платёж примерно 4 408 рублей в месяц).

Для поступления достаточно подать заявку через сайт, специальных требований или вступительных тестов нет.

7. Нетология — Инженер по тестированию

Ссылка на курс

Инженер по тестированию (QA-инженер) отвечает за проверку качества программного обеспечения, выявляя ошибки в веб-приложениях, мобильных сервисах и API. Курс от Нетологии обучает ручному и автоматизированному тестированию, включая работу с инструментами и языками программирования (Python, Java, JavaScript).

Программа предлагает три трека:

• «Ручное тестирование» для новичков;
• «QA-инженер уровня Junior» с основами автоматизации;
• «QA-инженер уровня Middle» с углубленным изучением JavaScript, мобильного и нагрузочного тестирования.

Студенты работают над реальными кейсами от партнеров — Dragons, OneTwoTrip и GOD.

📚Что получают выпускники

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

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

🎓Длительность и формат

• Курс проводится полностью онлайн, длительность зависит от трека: в среднем, 4–6 месяцев.

• Занятия включают вебинары по расписанию (не чаще 2 раз в неделю после 19:00 МСК), видеолекции, тесты и практические задания.

• На обучение требуется 8–10 часов в неделю. Формат сочетает синхронные вебинары с асинхронной работой через личный кабинет.

👥Кому подойдет

• Новичкам без опыта, студентам и специалистам из смежных сфер.

• Трек Junior подходит для начинающих, интересующихся автоматизацией, а трек Middle — для тех, кто хочет углубить навыки и претендовать на более высокие позиции. Базовый английский полезен, но программирование не обязательно для старта.

🏆Возможности стажировки и трудоустройства

Программа позволяет начать карьеру в ручном тестировании уже через 2 месяца обучения, на фрилансе или в найме.

Выпускники трека Junior могут начать карьеру младших QA-инженеров (медианная зарплата около 76 000 рублей), а трека Middle — на более сложные роли с зарплатой от 142 000 рублей.

💸 Стоимость и условия участия

Стоимость зависит от трека (цены указаны с учетом скидки 40%):

• Ручное тестирование: 56 700 рублей (или 2 487 рублей/мес. на 24 месяца)
• QA-инженер уровня Junior: 105 000 рублей (или 3 070 рублей/мес. на 36 месяцев).
• QA-инженер уровня Middle: 130 500 рублей (или 3 816 рублей/мес. на 36 месяцев).

Для поступления нужно подать заявку через сайт, вступительных тестов нет. Возможен возврат средств в течение 7 дней, если курс не подошел.

Как выбрать правильный курс под себя?

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

FAQ: частые вопросы от новичков

Можно ли войти в IT без высшего образования?

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

Реально ли устроиться после курсов?

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

Что выбрать: универсальный курс или узкую специализацию?

Зависит от вашей подготовки:

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

Так НЕ надо:

• Брать узкую специализацию «потому что все советуют», без анализа своих склонностей (например, идти в кибербезопасность, хотя нравится работа с данными).
• Выбирать универсальный курс в надежде потом определиться — это растягивает сроки выхода на рынок.

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

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

Почему это важно

Go часто критикуют за избыточную многословность в обработке ошибок. Код вроде:

становится настолько повторяющимся, что мешает восприятию логики программы. Попытки изменить это начались еще в 2018 году: сначала через check/handle, затем через упрощенный try, и недавно — с предложением использовать ?, как в Rust.

Однако ни одно из решений не устраивало всех: одно было слишком сложным, другое скрывало управление потоком, третье вызывало путаницу при отладке.

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

Что теперь?

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

• Ни один из подходов не получил консенсуса. Новая конструкция затронула бы весь экосистемный код, в отличие от, например, дженериков.
• В Go принято правило — «один способ делать вещи». Добавление альтернатив сломало бы этот принцип.
• Большинство пользователей Go на практике привыкают к текущему подходу и не считают его критичным.

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

А что с жалобами?

Ошибки продолжают занимать первое место в списке недовольств пользователей Go (после того как добавили дженерики). Но, как показала практика, не все хотят изменений ради краткости.

Особенно если это усложнит отладку или приведет к неидоматичному коду. Команда подчеркивает: они по-прежнему готовы выслушивать идеи — но не по синтаксису.

Вывод: для Go-мира все остается по-старому. Как и 15 лет назад, ошибки проверяются через if err != nil, и так будет еще долго.

Первые две части лежат здесь: рабочее место/облако и Fedora Core/mise.

Начало проекта и утилита make

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

Первый — классический пайплайн — это утилита make. Обычно она используется для сборки программ из исходного кода. На самом деле make хорошо подходит для решения сразу нескольких задач.

• Первая задача — отслеживание зависимостей одних файлов от других, например, при изменении сервиса пересобрать только соответствующий контейнер.
• Вторая задача, легко реализуемая через make — сборка в один файл много команд или скриптов, чтобы удобно их организовать. Как правило, сборка образа, его загрузка в репо, удаление временных файлов и прочее делается несколькими рутинными командами. Точно так же можно поместить в Makefile команды запуска сервисов и тестирование приложения локально.
• Если эти этапы прошли успешно, можно выполнить коммит кода в репо проекта, сделать деплой в dev или stage environment. В github actions это называется jobs и steps. В make такая группа команд называется целью, она указывается параметром при вызове.

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

Разбираемся на практике

Возьмём для примера проект с прокси сервером traefik и бэкендом на golang из репозитария awesome-pods. Этот репо задуман как форк замечательного проекта awesome-compose, в котором собраны конфиги docker compose для 41 самого популярного сервиса. Я же пытаюсь сделать что-то похожее для манифестов podman. Приглашаю к сотрудничеству начинающих девопс — сможете поучаствовать в открытом проекте, заработать почётные гитхаб-бейджи и улучшить своё резюме. Подробнее — здесь.

Мой проект в интересном положении: сделаны манифесты для нескольких сервисов, опробованы описанные выше подходы для миграции конфигов compose.yaml в манифесты kube.yaml. Но захотелось большего: а почему бы не сделать сразу пайплайны для тестирования, коммита в апстрим, деплоя и прочее. Зайдём в каталог traefik-golang и создадим пару мейк-файлов. Для начала сделаем всё это локально, начнём с make_compose:

Этот файл уже в истории, равно как и соответствующий README.md, привожу его для примера. Так как я делаю конфиги сразу для двух платформ — docker и podman, для включения соответствующего Makefile’а нужно сделать линк на него: ln -s make_compose Makefile.

Отлично, основную идею обсудили, идём дальше. В docker’е есть замечательная опция context, позволяющая работать с любыми серверами, где настроен доступ. В нашем случае список контекстов выглядит так:

Здесь я использовал простейший хак — сделал копию дефолтного контекста с именем localhost. Теперь мы можем сделать наш пайплайн способным на удалённый деплой. Достаточно прописать в /etc/hosts имя и адрес нашего dev сервера. Вот новая версия make_compose:

Поясню немного подробнее.

• Самая первая строка — стандартное объявление списка целей.
• Строки 2-4 задают дефолтное значение переменной, если оно не задано в текущем env.
• В хелп — строки 5-10 — добавлено предупреждение о текущем контексте, он задаётся в глобальной переменной, например, export DKR_CONTEXT=localhost для локального контекста.
• Также добавлена цель commit в репо — строки 17-21 — после выполнения цели test.
• Test — строки 31-32 — в свою очередь, выполняется для текущего контекста, см. хак #1. Имя контекста должно совпадать с именем хоста нашего dev-сервера.
• Добавлена также цель clean: очистка старых образов с локальном репо,и зависимости в цель up. Здесь убеждаемся, что образ пересобран и старые контейнеры остановлены.

Отлично, пайплайн для докера работает. Пробуем сделать то же самое для подмана. Здесь нас ждёт сюрприз, попробую рассказать в стиле прямого репортажа. Первоначально наш пайплайн для podman выглядел вот так:

В строке 5 определяются зависимости: target back соберёт исполняемый файл только в том случае, если код main.go или сам make_pods новее уже собранного бинарника.

Строка 6 удаляет backend контейнер с едва заметным знаком минус -, чтобы игнорировать ошибку, если контейнер с именем backend не существует.

Строки 7–10 создают контейнер с именем backend из пустого (scratch) контейнера — команды buildah следуют обычным командам Dockerfile, но в нижнем регистре: FROM -> from, COPY -> copy, RUN -> run, ENTRYPOINT -> config –entrypoint и т. д. Здесь вы видите основное отличие от традиционного docker buildx подхода — вы работаете в двух контекстах одновременно: в локальном контексте, используя установленный компилятор go, и в контексте контейнера, копируя файлы в/из контейнера, запуская команды внутри контейнера и т. д. Другая новая возможность buildah — вы можете собирать образ шаг за шагом, то есть отлаживать процесс сборки.

Строка 8 компилирует main.go в исполняемый файл back с соответствующими флагами.

Строка 11 создаёт из контейнера новый образ (image) с тегом backend:latest.

Цель up — строка 16 — зависит от цели down — строка 14, — то есть она сначала останавливает pod и удаляет контейнеры, если они всё ещё запущены, затем запускает новый под.

Цель down в строке 15 подставляет глобальную переменную $XDG_RUNTIME_DIR из env пользователя в kube.yaml, используемый далее в podman kube командах, принимая новый манифест со стандартного ввода. Это также специфика podman — он работает полностью в пространстве пользователя, контейнеры взаимодействуют через собственный podman.sock. Таким образом, делаем пайплайн независимым от UID.

В подмане есть фунциональность наподобие docker context, под другим именем, в подкоманде system connection:

Первым в списке стоит настроенная в прошлой статье ВМ. Пока искал правильные опции для создания коннекшена (aka контекст в докере), столкнулся с подсказкой от подмана — «создайте сначала машину», а именно:

Выполнил эти рекомендации, подман выкачал, настроил и добавил два новых коннекшена для новой ВМ. Какой же меня ждал сюрприз, когда я стал смотреть, что же это за machine. Во-первых, в моём HOME появились новые файлы и каталоги:

Во-вторых, это полноценная ВМ fedora coreos:

Конечно, приятно, что моё мнение совпало с мнением авторов подмана, точнее, со стратегией RedHat — fedora coreos наиболее подходящая система для контейнерных приложений. С другой стороны, ВМ в подмане крутится полностью внутри пространства пользователя. У меня уже настроена почти такая же для удалённой работы всей команды разрабов. Решено: останавливаем новую виртуалку и правим мейкфайл для подмана по образцу компоуза, делаем пайплайн для деплоя и локально, и на удалённый дев-сервер.

Но прежде нам понадобится ещё один хак #2. Если в случае докера переключение контекста можно было сделать любой переменной, то для подмана между локальным соединением через сокет и удалённым, через uri:ssh, имя переменной фиксировано CONTAINER_HOST. Вот как выглядит пайплайн make_pods.v1, настроенный и для локальной сборки, и для деплоя в наш дев-сервер:

По большей части цели мейкфайла остались теми же, но для удалённого деплоя настраиваем переменную export CONTAINER_HOST=ssh://dev@fc42dev:22/run/user/1001/podman/podman.sock — берём её из коннекшена, она служит переключателем между локальным и удалённым контекстом. Для локального контекста эту переменную надо удалить: unset CONTAINER_HOST. Команды в строках 19, 21 и 23 — это обычные команды шелла, они также меняются на локальное либо удалённое исполнение, переопределяются на основе этой же переменной CONTAINER_HOST.

Как заметил внимательный читатель, в цели back исчезла сборка контейнера утилитой buildah. Как и для docker compose, используется возможность самого подмана создавать образы на основе Containerfile, он же Dockerfile, эти названия синонимичны. Это намёк: пора отвыкать от слова докер, контейнеры уже давно стали основой облачных вычислений, для них созданы сотни приложений, например, CNCF и общепризнанные стандарты.

Принципиальный вопрос о контейнерах

Основное их преимущество — новый способ доставки приложений в облака, решение проблем с зависимостями, версиями библиотек, фреймворков и проч. Сборка контейнеров в контейнерах — побочный эффект облачных сервисов Github, Gitlab и других, с одной стороны, и ограничения Docker — с другой. Он не умеет, в отличие от подмана, точнее, от его сопутствующей утилиты buildah, выполнять билд и создавать образ, используя локальное окружение.

Основная проблема сборки образа внутри контейнера — неэффективное использование кэша. Да, появились возможности как-то сохранять объемные загрузки внешних библиотек, модулей: это опции --mount=type=cache для некоторых языков. Но, во-первых, эти возможности используются далеко не всегда. Во-вторых, опции для кэширования отличаются в podman и buildah, см. podman-build(1), придётся делать отдельный Containerfile. В-третьих, эффект от такого кэширования минимален. Предлагаю замерить время сборки, сделав ещё одну, третью версию пайплайна. Сначала соберём команды для buildah в отдельный файл:

и поправим пару строк в пайплайне:

Уточню условия нашего эксперимента — мы настроили одинаковую среду разработки с помощью утилиты mise (предыдущая статья) на нашем дев-сервере и у каждого из разрабов команды. Репозитарий git использует этот же дев-сервер, доступ к репо и серверу по ключу, парольный доступ закрыт. Пайплайны настроены как для локальной сборки, так и на дев-сервере. Перед запуском 3-й версии пайплайна на дев-сервере нужно сделать коммит изменений в репо — buildah не знает о коннекшенах, работает с кодом в текущем каталоге (строка 1): после логина на сервер переключается в корень проекта. Предварительно выкачиваем образ компилятора go для сборки в контейнере — это вполне честно, мы же выкачали и настроили компилятор golang заранее. Замеряем:

Мы получили 10+-кратный выигрыш по времени сборки образа для подмана. Абсолютные времена не важны, также не влияет, запускали мы сборку локально или на дев-сервере — мы сравниваем только билд в контейнере и в настроенном локальном окружении. Третье измеренное время — сборка в Docker. Он умеет собирать только в контейнере, для него настроили кэширование в Containerfile:

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

Ещё замечание: конечно, образы, собираемые buildah, совместимы с Docker, их можно использовать в конфигах compose.yaml. Но для этого надо настроить репозиторий образов и сначала загрузить образ в него. Локальные репозитории отличаются: Docker использует общий репо для всех пользователей — Docker Root Dir: /var/lib/docker, а в подмане всё хранится в домашнем каталоге пользователя — graphRoot: /home/$USER/.local/share/containers/storage.

Как я предположил в самом начале, мы попробовали вариант с гипотетической идеальной командой разрабов, работающей в Линукс и умеющей в make. А как быть обычному девопсу с разношерстой командой, где кто-то сидит на Винде, а кто-то ни за что не откажется от привычного Макбука на M4? Есть вариант и для этого случая. Пусть они пишут код и тестируют его как им нравится, а в нашем репо на дев-сервере мы сделаем хак #3, а именно git hook и bare репозиторий — githooks(5), выполняющий наши цели сборки и старта приложения при коммите в репо.

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

1. Заходим под юзером dev на сервер, создадим пустой каталог, например, mkdir -pv ~/bare/t0. Это станет новым GIT_DIR, зайдём в него и выполним cd ~/bare/t0;git init --bare.
2. Видим, что файлы, обычно спрятанные в каталоге .git, лежат прямо в корне. Сделаем дополнительно каталог для логов mkdir logs. Переходим в каталог hooks и создаём файл, где укажем команды выполнения при каждом изменении в репо.

Закомментированные строки 3, 8, 9 полезны при отладке пайплайна. Строки 4 и 5 задают, что есть, собственно, репозиторий, переменная GIT_DIR и переменная WORK_TREE (куда будут записываться файлы проекта). В цикле от строки 6 до 14 читаются и обрабатываются три переменные, с которыми гит вызывает этот хук. Строка 11 принимает все изменения в репо и обновляет WORK_TREE — всё то, что гит обычно делает в общем каталоге, как видим, в bare репо они разные. Далее, в 12 строим имя лога и строка 13 — собственно, пайплайн.

1. Идём в каталог, где расположен репо проекта. Без страха и сожаления удаляем старый и создаём новый под тем же именем: cd ~/src;rm -rf traefik-golang;mkdir traefik-golang.
2. Завершаем сессию на дев-сервере, возвращаемся на рабочий комп и заходим в репо проекта. Конечно, репо цел, клоны репо не так просто уничтожить, пока есть хотя бы одна копия. Теперь смотрим старые настройки git remote -v и удаляем их git remote remove fc42dev в моём случае. Создаём новый remote, указывая новый гит bare репо: git remote add bare.t0 dev@fc42dev:~/bare/t0. Это также нужно сделать всем разрабам в их локальных копиях.
3. Проверяем результат. Возможно, нужно сделать новый комит и push в новый remote. Стоит посмотреть подробнее, как изменился репо проекта на сервере: проверить логи в ~/bare/t0/logs, сравнить конфиги обычного репо проекта и на сервере, проверить, какие команды перестали работать в серверном репо. Например, в WORK_TREE не работают команды гит status; branch; commit; log. То есть наш хак #3 с git --bare не только позволил делать деплой на сервере, но также защитил репо от локальных изменений, а серверный репо всегда в чистоте и порядке. Можно редактировать код, но закомитить его только через обычный репо. Изменения на сервере удалятся после любого коммита.

Надеюсь, мне удалось показать, что пайплайны можно делать на основе древней забытой утилиты make. В следующей статье разберём, как можно добавить в наш скромный дев-сервер нечто похожее на монстров гит-сервисов, Gitlab и Github, создавать пайплайны, совместимые с github Actions, предоставить команде разрабов привычный интерфейс репо в браузере.

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

В конце ты получишь 1–2 языка, которые соответствуют твоим приоритетам, плюс пояснение, где они реально применяются, зачем их учить и как с ними выстраивать карьеру.

Он использовал компилятор TinyGo, SDK ps2dev и собственные костыли, чтобы адаптировать современный язык программирования под устаревшую архитектуру.

TinyGo, MIPS и странности платформы

PS2 построена на процессоре MIPS R5900 (архитектура MIPS-III с расширениями), который не поддерживается стандартной сборкой Go. Проблему частично решает TinyGo, который компилирует Go-код в LLVM IR.

Но даже с ним возникли сложности: ни LLVM, ни сам TinyGo не умеют работать с особенностями PS2 «из коробки». Пришлось вручную описывать платформу через ps2.json, определять baremetal-окружение, runtime и заглушки под прерывания.

Первые успехи: «Hello from Go»

Чтобы код TinyGo можно было линковать с библиотеками из ps2dev (а они скомпилированы под ABI N32), автору пришлось добиваться совместимости: целиться в MIPS-III, использовать hard-float, отключать abicalls и собирать IR с последующей ручной сборкой объектника через Clang с нужными флагами.

После успешного линка и запуска в эмуляторе PCSX2 программа вывела строку и число на отладочный экран PS2.

Собственный main() и отладка

Дальше автор отказался от загрузчика на C и написал полноценный main() на Go, вручную выделяя память под кучу и завершая программу через exit() из ps2dev. Он добавил простую обёртку над scr_printf() — теперь можно печатать текст прямо из Go.

DDIVU и проклятие деления

Серьёзным багом стал сбой fmt.Sprintf: PS2 не поддерживает инструкцию DDIVU, которую LLVM генерирует при делении uint64.

Автор обошёл это, подключив функции __udivdi3, __divdi3 и прочие, а затем пропатчил компилятор TinyGo, чтобы он использовал их при делении int64 и uint64.

Что дальше

Демо работает. Go-код запускается напрямую, выводит текст и корректно делит числа.

Впереди — системные вызовы, inline-ассемблер, поддержка прерываний и, возможно, новая цель в LLVM для процессора r5900.

Новость быстро разлетелась по сообществам, но на деле всё не так однозначно, пишет разработчик Оскар Дудич в рамках Architecture Weekly.

Речь идёт о скорости компиляции, а не исполнения кода. Ваши приложения не станут работать быстрее — только собираться. Это как если бы производитель автомобилей сказал, что «машина стала в 10 раз быстрее», а потом уточнил, что речь о производстве, а не скорости на трассе.

Почему решили переписать и причём тут Go

Компилятор — это CPU-bound задача. Он не ждёт ответа от базы данных и не занимается сетевыми запросами. Он грузит процессор на полную, разбирая дерево типов, анализируя код и генерируя выходной файл.

Node.js с его однопоточной моделью и event loop плохо подходит для таких задач. Он отлично работает в веб-серверах — там важна скорость отклика и работа с I/O, но не тяжёлые вычисления. Компилятор TypeScript вырос, стал сложнее, и старая архитектура начала тормозить.

Go здесь оказался подходящим выбором:

• у него есть легковесные потоки (goroutines);
• параллельное выполнение встроено на уровне языка;
• нет нужды в трюках с worker threads, как в Node.js;
• проще работать с памятью и сложными структурами.

Почему просто не использовать worker threads в Node.js?

Это возможно, и они действительно дают параллельность. Но:

• переписывать старый код с учётом многопоточности — больно;
• обмен данными между потоками в Node.js идёт через сериализацию;
• каждый поток создаёт свой V8-инстанс, что дорого по ресурсам.

Команда решила не латать старое, а начать с чистого листа. И, как показали первые тесты, даже однопоточный Go-компилятор оказался быстрее, чем старый на Node.js.

А что с браузерами и плагинами?

Это пока не ясно. В браузерах Go не работает нативно, и придётся либо компилировать его в WebAssembly, либо сохранить JS-версию для playground'ов. Вопросов больше, чем ответов:

• как сохранить совместимость с TypeScript-плагинами;
• будет ли 100% повторяемость в поведении компилятора;
• изменятся ли ошибки, предупреждения и тонкости типов.

Зачем вообще об этом думать

Это кейс о масштабировании и выборе инструментов. То, что хорошо работало в 2012 году, перестаёт тянуть в 2025-м. Переписывание проекта — не всегда трагедия. Иногда это необходимость, если фундамент начал мешать росту.

Важно не повестись на «10x быстрее». Такие цифры всегда требуют контекста. Но и отрицать ценность изменений не стоит — особенно если вы работаете с большими кодовыми базами и каждый процент ускорения важен.

Я — Даниил Динько, веду свой личный телеграм-канал, где рассказываю о себе, об IT и о Golang. Также являюсь экспертом и спикером в компании Эйч Навыки, TeamLeadом в компании-лидере в международном кибербезе, ex. старшим разработчиком в Ozon Tech. Вместе разбираемся, что объединяет Go-разрабов каждого грейда.

А почитать о том, как сейчас стать Go-разрабом, можно в предыдущей статье.

Навык собеседований vs. навык работы

Для начала важно разделять два понятия: навык прохождения собеседований и навык работы. Интервью длится 3-4 часа — этого невероятно мало, чтобы прочувствовать весь ваш кругозор в бою, поэтому индустрия использует стандартные задачи-заглушки. У большинства компаний такие задачи примерно про одно и то же, поэтому сейчас не редка ситуация, когда на собеседовании ваш реальный грейд на единицу или полторы выше реального — как раз потому, что такие заглушки отскакивают от зубов.

• Что это значит для кандидата: в такой ситуации можно быстрее вырасти в реальном навыке работы, потому что через навык собеседований вы получаете грейд. Эти задачи не даются просто так на позиции, которая соответствует навыку реальной работы. Так, в стрессовой ситуации вы максимально выравниваетесь за короткий срок.
• Что это значит для компании: для работодателя это плохо, поскольку определить грейд — еще сложнее. И есть шанс нанять кандидата, на которого потратят больше денег, чем он теоретически может принести.

Теперь разберем, что требуется от Go-разработчиков на каждом уровне.

Что нужно с точки зрения навыка собеседований

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

Дисклеймер: не обязательно знать все из списка ниже — в нем представлено максимальное количество навыков и верхняя граница знаний по грейду. Поэтому если вы что-то не знаете, это отличный способ понять, что наверстывать.

Грейд: Junior

Сейчас на рынке Go очень много джунов — он перегрет, и попасть в компанию без коммерческого опыта будет крайне сложно. Более того, от начинающих разработчиков ждут немало знаний и навыков. О них — ниже.

Углубленное знание Go

• Уметь абстрактно рассказать про очереди в планировщике.
• Знать про мапу под капотом: как устроено хеширование, коллизии и разрешение конфликтов.
• Уметь решать задачи по concurrency на относительно базовом уровне (воркер пул) и на слайсы
• Понимать принципы работы горутин и каналов.

Базы данных

• Знать виды баз данных и рассказать про максимальное количество юзкейсов из опыта с разными типами данных.
• Знать индексы и ACID и уметь их базово писать.
• Знать SQL, уметь составлять схемы и идейно понимать, как работают самые известные базы — PostgreSQL, ClickHouse.
• Понимать репликацию и шардирование

Системный дизайн

Да-да, теперь даже джуну нужно иметь абстрактное понимание сисдиза:

• Монолит vs. микросервисы: знать плюсы и минусы каждой архитектуры.
• Знать варианты коммуникаций между сервисами (брокеры сообщений, REST API, gRPC).

Алгосы и Computer Science

• Уметь решать медиум-задачки на LeetCode. Фокус при этом на задачах со слайсами, деревьями и графами.
• В Computer Science — знать про устройство Linux, планировщик, потоки/процессы, а еще про устройство сети — OSI, TCP/IP, протоколы и т.д.

Также в некоторых компаниях сейчас ко всему этому требуют еще и знание Kubernetes.

Вот здесь собрал дорожную карту, как влиться в IT на примере Go. Из полезных ссылок:

1. Один из лучших курсов по Go на Youtube
2. Крутой урок по системному дизайну
3. Все про каналы в Go

А здесь можно посмотреть, как джуну стать мидлом.

Грейд: Middle

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

Go

• Знать планировщик на уровне того, какая структура данных используется в локальных очередях.
• В слайсах — уметь решать задачи со срезом по capacity, плюс более уверенное решение кейсов по concurrency.

Базы данных

• MVCC,
• Проблема разбухания индексов,
• Селективность,
• Шардирование на уровне реальных решений основной проблемы решардинга — Consistent Hash,
• Реприликация и паттерн Raft.

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

Сисдиз

Нужно знать про паттерны межсервисного взаимодействия: Saga, Transactional Outbox, Circuit Breaker. На мидла могут уже спокойно давать практические задачи на внедрение каких-то идейных дизайнерских штук, например, идемпотентности.

Алгосы и Computer Science

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

Грейд: Senior

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

Go

Нужно знать библиотеку Reflection со всякими приколами, которые могут ускорить concurrency. Также разбираться в аренах памяти и планировщике.

Сисдиз

В паттернах межсетевого взаимодействия история с обычным рассказом не пройдет — юзкейсы здесь must-have. Поэтому важно уметь проходить System Design-интервью — собирать функциональные и нефункциональные требования, считать нагрузку, проектировать на разных уровнях абстракции, углубляться и решать проблемы в своей же архитектуре. Это сложно, и без хотя бы косвенного соприкосновения с проектированием, будет непросто. Поэтому в качестве совета — стремитесь максимально участвовать на архитектурных сессиях и грумингах, будучи мидлом.

Базы данных

Будет круто знать, как под капотом реализован, например, PostgreSQL: как он поднимает что-то в буфер, как хранит данные на диске, что такое чекпоинты и бэкапы и как реализована MVCC.

В случае с ClickHouse лучше верхнеуровнево понимать LSM-дерево, а с ElasticSearch — инвертированные индексы.

Алгосы и Computer Science

Алгоритмы уже почти не играют роли в большинстве компаний, а Computer Science требуется примерно на том же уровне, что и на джуна. Единственное — в Linux могут чуть капнуть.

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

Мне часто на трансляциях говорят: «Зачем мне знать планировщик или уметь решать сложные задачи по concurrency? Когда мне это пригодится в работе?». Действительно, на эффективность в решении рабочих задач это влияет незначительно, но все же это особенность собеседований (подробнее можно посмотреть здесь):

• Собес ≠ работа. Принято считать, что знания, требуемые на собеседовании, пригодятся в работе — это не так. За несколько часов невозможно полностью оценить кандидата, поэтому интервью строятся на проверке общих знаний и концепций.
• Почему спрашивают про планировщик? Банально узнают софты.
• Жесткая конкуренция. Все просто: знание — сила.

Что нужно с точки зрения реальной работы

На мой взгляд, самое важное, помимо знания технологий — прокаченные софт-скиллы. И наработать их можно только с опытом.

• Грейд Junior. Нужно уметь делать максимально базовые задачи. Например, добавить поле или прокинуть фича-флаг. Или же при курировании и ревью быть мотивированными. Этого достаточно. Да, как бы грустно это ни звучало, здесь по классике предполагается, что тебе нельзя доверить что-то серьезное без сторонней помощи.
• Грейд Middle. Относительно безболезненно брать на себя полноценные части продукта в зону ответственности, фича-лидить. Здесь предполагается, что ты можешь действовать относительно самостоятельно, приходя с вопросами лишь иногда. Тут уже желательно участвовать в каких-либо технических обсуждениях.
• Грейд Senior. Здесь нужно разрабатывать фичи любого уровня сложности под ключ. Тебе достаточно предоставить бизнес-требования, сходить с ними по командам с экспертизой. Затем спроектировать качественную архитектуру, которая развалится с минимальной вероятностью, самому реализовать и принести лиду таску в Done. Здесь также важно менторить сотрудников, активнейшим образом участвовать на грумингах и любых других технических созвонах.

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

Я — Даниил Динько, веду свой личный телеграм-канал, где рассказываю о себе, об IT и о Golang. Также являюсь экспертом и спикером в компании Эйч Навыки, TeamLeadом в компании-лидере в международном кибербезе, ex. старшим разработчиком в Ozon Tech. Вместе разбираемся, что нужно тем, кто только знакомится с Go, для старта в IT.

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

Кстати, в следующей статье я собрал стартер-пак Go-разрабов на каждом грейде — почитать можно здесь.

Для начала: почему Golang на хайпе

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

Мне кажется, Go валиден почти в любой сфере. Его основные преимущества:

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

Хотя не обязательно высоконагруженную: Go используют на всех уровнях бизнеса.

Также в Go крутые зарплаты — в основном, выше рынка. Новички могут получать от 100 000 рублей в месяц, а сеньоры — даже 500 000. В среднем — 160 000 рублей.

Какие есть подходы для старта карьеры

Глобально есть четыре подхода:

1. Курсы. Вас ведут за ручку и не нужно ничего самому искать. Есть мотивация, но нет прокачки двух самых важных навыков — поиска информации и самообразования.
2. Менторство. На начальных этапах вообще не рекомендую, оверхед, лучше думать в сторону курсов.
3. Сообщество. Здесь вы объединяетесь с другими начинающими ребятами. Это лучший вариант — бесплатно, сохраняются все преимущества, за исключением того, что придется самому вести себя за ручку и искать всю нужную информацию. Но в начале должно быть именно так. В сообществе вы идете командой, и с корабля просто так не спрыгнешь: будет банально неудобно перед другими ребятами.
4. Расти самому. Плюсов меньше, чем в варианте выше, а минусов — больше. Например, нет видимой конкуренции и взаимной мотивации друг друга.

Я рекомендую третий вариант: практика показывает, что он самый эффективный в плане процента «доходимости». Единственное, в его рамках предстоит решить несколько вопросов.

Как найти таких людей, с которыми можно будет вместе двигаться?

Тут довольно просто: беседы в Telegram, воронки, взлетевшие видео на ютубе по Go — их полно. Например, этот курс считаю одним из лучших. Поэтому план простой: находим подобное видео, переходим в беседу, в ней ищем себе товарищей, списываемся, предлагаем совместный рост и созваниваемся.

Крайне важно правильно выбрать себе друзей, поскольку они будут играть значительную роль в вашем становлении разработчиком. Основные критерии, по моему мнению, — мотивация к работе (горящие глаза), детерминированная причина стать Go-разработчиком, идейная заинтересованность в программировании, уровень силы воли и организованности человека (без этого никак).

Как найти человека, которому можно задавать свои вопросы?

Тоже все просто. Во многих tg-каналах, например, в моем, открыты комментарии, и в них часто можно увидеть полотна текста. Вероятно, автор комментария заинтересован обсуждать Go и учить других. При этом, его уровень будет довольно высоким, поэтому спокойно пишите и начинаете задавать вопросы. А вообще в моих ближайших планах — создать коммьюнити, в котором каждый сможет получить такую помощь еще более простым путем.

*А еще не забываем про ChatGPT или DeepSeek — они должны быть вашими основными консультантами.

Так, мы нашли людей, с которыми будем двигаться вместе, и тех, у кого будем спрашивать. Теперь давайте ответим на последний вопрос.

Как учиться?

Пока мы не умеем учиться сами, поэтому задача — экстерном влететь в этот навык. Здесь лучшее бесплатное предложение — Learning How to Learn от Coursera (оно на английском, но есть субтитры). Там собрались эксперты, профессора крупных университетов, чтобы научно подойти к вопросу и дать практические советы по тому, как можно эффективно обучаться. Честно говоря, сам бы пересмотрел курс, если бы было больше свободного времени. Считаю его лучшим вариантом вкатиться в эффективное самообразование. Особенно рекомендую обратить внимание на технику помидоров, она, мне кажется, значительно ускоряет перформанс.

Главное: какие есть пути вката в разработку на Go

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

А теперь — об основных путях «входа в айти».

Стажировки

Чтобы попасть на программу, рекомендую решать каждый день 2-3 задачки с leetcode.com (Если совсем тяжело — сначала решаем на codewars.com, а потом переходим на литкод). Затем, все просто (ну, почти): стучимся во все возможные наборы на стажировку в бигтех: Ozon Route 256, VK, Т-Банк, школа стажеров Wildberries — перечень можно легко найти в Гугле. Вариант довольно сложный и требует в большинстве случаев хорошую алгоритмическую подготовку. Но она нарабатывается за 3-4 месяца ежедневного решения задач на leetcode, кажется, не так много. Навык решения алгоритмических задач будет на протяжении всей карьеры расширять список потенциальных компаний для трудоустройства, так что временная инвестиция вполне валидная.

Бесплатные стартапы

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

Накрутка опыта

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

Желаю самого успешного роста и верю, что если следовать по плану, описанному в этой статье, у вас все получится! Главное — уделяйте большое внимание моральной составляющей. Мотивация будет не всегда, поэтому пока она есть — максимально быстро конвертируем ее в силу воли.

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

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

Я — Семен Шаплыгин, Senior Software Developer в Yandex и экспертом Эйч Навыки. В статье расскажу о пяти главных шагах для защиты backend-приложений от уязвимостей. Поделюсь инсайтами и практическими советами, которые позволят избежать распространённых ошибок и уберечь систему от возможных атак.

Аудит безопасности: с чего начать

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

Подход к выявлению слабых мест должен включать несколько ключевых практик (запомните их, как мантру):

• Ваш код может быть чистым, но уязвимость скроется в одной из библиотек. Инструменты для анализа зависимостей должны работать на каждом этапе разработки.
• Никогда не доверяйте тому, что приходит от пользователя. Любой ввод — это потенциальная атака.
• Чувствительные данные не должны попадать в журналы ошибок или системные логи.
• Любому компоненту системы дается только тот уровень доступа, который ему необходим. Ни строчкой больше.
• Критически важные функции должны периодически проверяться на уязвимости.
• Используйте специализированные инструменты. Это не только статический и динамический анализ кода, но и мониторинг активности, поведенческий анализ трафика.
• Если в публичном пространстве появляется информация о скомпрометированных данных — в числе первых она должна оказаться у вас.

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

Чек-лист защиты backend: 5 ключевых шагов

Шаг 1. Защита от XSS: экранируйте ввод и вывод

Проблема:

XSS (межсайтовый скриптинг) — уязвимость, позволяющая злоумышленнику внедрить вредоносный код в веб-страницу, которая затем появится в браузере других пользователей.

Что делать:

Для предотвращения XSS необходимо экранировать выводимые данные, используя функции, которые преобразуют специальные символы в HTML-сущности. Например, для шаблонов Go можно использовать html/template вместо text/template, что обеспечивает автоматическое экранирование данных.

Пример:

Мы выводим пользовательский ввод (заголовок и содержание поста) напрямую в HTML без экранирования, что позволяет внедрить JavaScript-код, если он по каким-то причинам ранее попал в базу. Чтобы это исправить, достаточно использовать библиотеку "html/template"

Шаг 2. Защита от CSRF: используйте токены

Проблема:

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

Что делать:

Пользователь открывает форму для создания поста. Если злоумышленник заставит пользователя отправить запрос POST /post, например, через <img src="http://example.com/create?title=Hacked&content=Malicious" />, сервер выполнит этот запрос, не проверяя, кто его отправил.

Для защиты от CSRF необходимо использовать специальные токены, которые уникальны для каждого запроса. Они проверяются сервером, и если токен отсутствует или недействителен, сервер отклоняет запрос. Один из вариантов — привязка CSRF-токенов к пользовательской сессии, что исключает возможность использования токенов другого пользователя злоумышленником. Для вашего удобства — библиотеки по типу gorilla/csrf, которые обеспечивают защиту от CSRF-атак.

Дополнительно можно повысить уровень безопасности путем проверки заголовков Referer или Origin в POST-запросах, чтобы убедиться, что запрос поступил с доверенного источника. Также полезно ограничить CORS (Cross-Origin Resource Sharing), чтобы только определенные сайты могли отправлять запросы к вашему серверу.

Пример:

Чтобы исправить проблему, нужно создать CSRF-токен и проверять его во время создания поста.

Измененный метод для страницы создания поста:

Измененный метод сохранения поста:

Шаг 3. Контроль доступа: избегайте уязвимостей IDOR/Broken ACL

Проблема:

Все это — недостатки контроля доступа IDOR/Broken ACL. Данная проблема возникает, когда приложение позволяет пользователю получить доступ к ресурсам или действиям без надлежащей проверки прав. Это часто происходит, если доступ к ресурсам идентифицируется по значениям ID, которые можно предсказать или изменить.

Что делать:

Чтобы избежать уязвимостей IDOR и Broken ACL, нужно проверять права пользователя перед предоставлением доступа к ресурсам. Рассмотрим пример со следующим сниппетом кода.

Пример:

На сайт добавили возможность просматривать конкретный пост, если его передать в путь запроса /post/{{post_id}}

На первый взгляд, выглядит надежно. Но на самом деле нет проверки, принадлежит ли пост текущему пользователю. Это позволяет злоумышленнику получить доступ к любому посту, зная только его post_id.

Чтобы это исправить, достаточно в запросе указать признак пользователя:

Дополнительно стоит пересмотреть использование числовых идентификаторов постов, так как целочисленные значения можно легко перебирать. Например, злоумышленник может просто увеличить post_id и попытаться получить информацию о постах с большими ID, чтобы оценить популярность вашего сервиса по сравнению с конкурентами. Чтобы избежать этой проблемы, рекомендуется использовать UUID версии v7. Этот тип идентификаторов спроектирован так, чтобы хорошо работать с базами данных и не поддаваться простому перебору.

Шаг 4. Не храните конфиденциальную информацию в открытом виде

Проблема:

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

Что делать:

Для того, чтобы избежать раскрытия конфиденциальных данных, нужно не включать их в ответы API. Достаточно уменьшить уровень логирования для чувствительных данных, либо применить обфускацию конфиденциальных. Также советую избегать явного хранения секретов в коде.

Пример:

Обратим внимание на схему хранения данных пользователей:

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

Для этого рекомендую использовать криптографическую хэш-функцию (Argon2 или её модификацию Argon2id). Этот алгоритм обеспечит надежное и безопасное хранение паролей.

Чтобы исправить текущую проблему, необходимо внести следующие изменения в код:

1. Для работы с алгоритмом Argon2 следует использовать эту библиотеку.
2. При регистрации пользователя записывать в базу данных только хэш пароля, а не сам пароль. Это выглядит следующим образом:

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

Шаг 5. Защита от SQL-инъекций: используйте подготовленные запросы

Проблема:

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

Что делать:

Для защиты от SQL-инъекций важно всегда использовать подготовленные выражения. Это гарантирует, что пользовательский ввод будет экранирован и не интерпретируется как часть SQL-запроса. Вместо того, чтобы вручную собирать запросы, всегда передавайте параметры через символы ? или $1, в зависимости от используемой базы данных. Советую никогда не добавлять данные напрямую в строку SQL-запроса, поскольку это открывает возможность для SQL-инъекций.

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

Пример:

Для защиты от SQL-инъекций достаточно использовать подготовленные выражения, что значительно повышает безопасность приложения. В примере выше достаточно просто заменить строку запроса на использование параметризированных запросов:

Если вы работаете с более сложными запросами в Go, то можно использовать библиотеку squirrel, которая помогает безопасно строить запросы и избегать ошибок при работе с SQL.

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

Кроме того, хочу обратить внимание на еще одну важную практику, которая часто упускается — использование инструмента golangci-lint. На данный момент это стандарт для разработчиков Go, хотя иногда можно встретить проекты, где инструмент не используется. Он позволяет автоматически находить уязвимости, ошибки и антипаттерны в коде на ранних стадиях разработки. В состав golangci-lint входит статический анализатор gosec, который ориентирован на поиск проблем безопасности. Использование инструмента помогает существенно снизить риски ошибок в продакшене. Для других популярных языков программирования также существуют аналогичные инструменты, которые стоит учитывать при разработке.

Перспективные технологии и подходы в защите backend

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

Zero Trust Architecture (ZTA) или Zero Trust Policy (ZTP)

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

Гомоморфное шифрование (Homomorphic Encryption)

Это метод, который позволяет выполнять вычисления с зашифрованными данными, не расшифровывая их. Результаты вычислений могут быть открыты только после завершения операции. Такой подход особенно полезен в ситуациях, когда данные нужно обрабатывать сторонними системами и сохранять их конфиденциальность. Например, в законодательстве РФ существует ответственность за утечки персональных данных, что может привести к серьезным финансовым потерям или даже закрытию бизнеса. Гомоморфное шифрование помогает решить эту проблему, обеспечивая обработку данных без их раскрытия.

DevSecOps

Это подход, который интегрирует безопасность в процессы разработки и эксплуатации на всех этапах жизненного цикла ПО. Акцент делается на автоматизацию, сотрудничество и постоянное улучшение безопасности. Главная цель DevSecOps — сделать безопасность не отдельным этапом, который следует после завершения разработки, а неотъемлемой частью культуры и процессов проекта.

Навыки backend-разработчика, которые защитят его от уязвимостей

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

В первую очередь — глубокое понимание принципов безопасности. Это включает в себя знание распространённых уязвимостей — SQL-инъекции, XSS, CSRF, SSRF и другие угрозы из списка OWASP. Важно также осознавать принципы минимизации привилегий и безопасного проектирования.

Неотъемлемая часть работы — практика безопасного программирования. Разработчик должен уметь работать с механизмами аутентификации и авторизации — OAuth 2.0, OpenID Connect и JWT, а также использовать защищённые соединения (TLS/HTTPS) и шифрование (AES, RSA).

Отдельного внимания заслуживает безопасность API. Инженер должен понимать, как проектировать защищённые интерфейсы, применять ограничения на частоту запросов, валидацию входных данных и проверку токенов. Кроме того, важно уметь работать с инструментами безопасности — SAST (SonarQube, Checkmarx), DAST (OWASP ZAP, Burp Suite) и SCA (Snyk, Dependabot).

Разбираясь в инфраструктуре и безопасности развертывания, разработчику необходимо уверенно управлять контейнерами (Docker, Kubernetes), работать с облачными сервисами (AWS, Azure, GCP) и использовать встроенные механизмы защиты. Также важно понимать принципы мониторинга и реагирования на инциденты: анализировать логи, настраивать системы оповещения и оперативно реагировать на угрозы.

Для повышения уровня безопасности команде пригодится не только обладать знаниями, но и регулярно их обновлять. Начать можно с изучения рейтинга OWASP Top 10, в котором собраны наиболее актуальные угрозы. Однако теория без практики бессмысленна, поэтому стоит использовать платформы для тренировки — Hack The Box, PortSwigger Academy и PentesterLab.

Внедрение DevSecOps-подходов значительно повышает защищённость системы. Автоматизированные инструменты — статический анализ кода (SAST), динамическое тестирование (DAST) и анализ зависимостей (SCA), должны быть интегрированы в процесс CI/CD.

Дополнительно можно организовать внутренние соревнования в формате Capture The Flag (CTF), чтобы вовлечь команду в процесс, и повысить уровень её осведомлённости. Если этот формат вам незнаком, можно изучить примеры, например, соревнования, проводимые Google — Google CTF.

Периодические анонимные проверки на уязвимости — тесты на фишинг или моделирование атак через подмену точек доступа, помогут выявить слабые места и укрепить защиту.

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

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

Полезные материалы по статье

• Топ-10 уязвимостей в веб-приложениях в 2021–2023 годах в Securelist от Kaspersky
• Доклад от Positive Technology «Уязвимости и угрозы веб-приложений в 2020–2021 гг»
• Публичная статистика bug bounty от компании Яндекс за 2024 год
• Репозиторий с исходным кодом проекта, где лежат примеры из статьи
• Топ-10 уязвимостей в веб-приложениях в 2021 году от организации OWASP
• Инструмент golangci-lint
• Примеры проведения CTF от компании Google
• Исходный код хэш-функции Argon2

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

Речь идёт о поддельном модуле boltdb-go/bolt, который маскировался под популярную библиотеку boltdb/bolt.

Этот пакет — зависимость для более чем 8000 других проектов, что делает атаку особенно опасной.

Как это произошло?

Хакеры использовали метод «типосквоттинга»: создали почти идентичное название, надеясь, что кто-то ошибётся при вводе команды. Вредоносный код появился ещё в 2021 году и попал в кэш Go Module Mirror.

После этого злоумышленники стерли следы — обновили репозиторий на GitHub, заменив бэкдор чистым кодом. Однако механизм Go не очищает закэшированные версии, поэтому прокси продолжал раздавать заражённый пакет.

Что делал бэкдор?

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

Сервер для управления атакой находился в сети Hetzner Online — уважаемого хостинг-провайдера. Это помогло обойти антивирусы и затруднило обнаружение атаки.

Почему это заметили только сейчас?

Компания Socket обнаружила бэкдор только в конце января 2025 года.

Они сразу же запросили его удаление, но Google не торопилась. Лишь после второго обращения 3 февраля заражённый модуль был исключён из Go Module Mirror.

Какие выводы?

Этот случай успешно продемонстрировал уязвимость механизмов кэширования.

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

Что делать?

• Внимательно проверять имена пакетов перед установкой.
• Использовать инструменты безопасности, анализирующие зависимости.
• Требовать от Google и Go Team улучшения защиты Go Module Mirror.

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

Как отображать анимацию NFT-подарков?

Для начала рассмотрим контракт, который содержит данные о NFT-подарке:

0:3a4f57aded85be8f7d1651b8e9d7749662014e08f6bcd3afaf2175c83188a7da

Из этого контракта можно получить всю необходимую информацию: атрибуты, описание и т.д. Эти данные можно запросить через API или вручную, нажав кнопку More в интерфейсе:

Там мы видим ссылочку с поясняющим ключом и именем:

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

Как отобразить анимацию в вашем приложении?

Lottie — библиотека, разработанная компанией Airbnb. Позволяет отображать анимации в формате JSON, созданные с помощью AdobeAfter Effects. Благодаря Lottie разработчикам можно легко интегрировать высококачественные анимации в мобильные и веб-приложения, обеспечивая плавность и масштабируемость без значительного увеличения размера.

Применим на практике. Отобразить анимацию в вашем web. или TMA приложении проще простого, через библиотеку lottie-web.

В этом случае код будет выглядеть так:

Под разные языки есть также библиотеки для работы с форматом. Однако, в некоторых случаях, людям приходят странные идеи конвертировать анимацию:

• через ffmpg в mp4 (больший размер);
• покадрово в gif (потеря качества и размера);
• через webview.

Моя задача состоит же в отправке анимации пользователю непосредственно в Telegram. Логично, что формат хранения в Lottie выбран не просто так. Довольно много NFT хранятся в mp4, gif, webm.

Разгадка кроется не только в компактном размере данного формата, но и в устройстве Telegram стикеров.

Для решения задачи используем следующую схему:

1. загружаем https://nft.fragment.com/gift/hexpot-10348.lottie.json;
2. сжимаем в gzip;
3. отправляем в Telegram, например, в виде документа.

На golang это может выглядеть так:

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

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

P.s. Всегда готов ответить на ваши вопросы. Пишите в тг @apitonDev.

Большинство сервисов в хайлоаде, работу которых мы логируем и исследуем, давно переписаны на Go. Из-за этого часто необходимо переиспользовать логику сервиса внутри аналитического или ML-приложения на Spark. Как примеры такого кода можно взять расчёт скоров по сложному запросу или ранжирование айтемов для выдачи.

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

Немного о нашей инфраструктуре

Наша платформа построена на классической связке Hadoop/YARN/Spark/PySpark. Основной язык разработки — Python 3.11. Мы стараемся придерживаться баланса между зрелостью и актуальностью софта, чтобы не погрязнуть в поддержке легаси решений. Для этого мы долго обучали разработчиков и аналитиков писать тесты для их задач.

Изначально Python был выбран вместо Scala, чтобы снизить порог входа и дать возможность каждому работать с продуктовым кодом вместо выделенной команды бигдата-инженеров, реимплементирующих код от аналитиков и ML.

В типичных цикл разработки входит:

• Проектирование — обсуждаем и подготавливаем данные для задачи, эксперимента, проговариваем примерную реализацию.
• Прототип в Jupiter ноутбуках, первое ревью, проверяем надёжность и качество исходных данных.
• Упаковываем задачу в формат Airflow, настраиваем, покрываем тестами и тестовыми данными, настраиваем метрики.

Для аналитики работы сервисов мы обычно используем пайплайн с логированием JSON структур в Kafka, данные из которой в HDFS поставляет задача на Flink. Реплей таких логов на кластере через PySpark UDF — об этом и написана статья.

CGO, или собираем биндинг дешево

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

Тут есть несколько подходов:

• Довериться генератору биндингов, например GoPy. Самое очевидное решение, которое мы и попробовали в первую очередь. К сожалению, результат был негативным:биндинг содержит много мусора и ненужных артефактов;требуется дополнительно его патчить, не всё работает «из коробки»;структуры биндинга уродливы, над ними нужна ещё одна обертка;код неэффективен;собранный пакет жёстко привязывается к определённой версии интерпретатора — у нас есть несколько версий и дистрибутивов Python.
• биндинг содержит много мусора и ненужных артефактов;
• требуется дополнительно его патчить, не всё работает «из коробки»;
• структуры биндинга уродливы, над ними нужна ещё одна обертка;
• код неэффективен;
• собранный пакет жёстко привязывается к определённой версии интерпретатора — у нас есть несколько версий и дистрибутивов Python.

Поэтому такие биндинги не очень долго прожили — требовали постоянного внимания.

• Написать биндинг вручную. Существует много туториалов, как это сделать, но есть сложности:поддержка однообразных структур и кода на С;есть привязка к ABI Python, нужна сборка под конкретный Python;чтобы поддерживать в актуальном виде, нужно время квалифицированного разработчика.
• поддержка однообразных структур и кода на С;
• есть привязка к ABI Python, нужна сборка под конкретный Python;
• чтобы поддерживать в актуальном виде, нужно время квалифицированного разработчика.

• Использовать сериализацию в промежуточный формат. Плюсы:если это JSON, то сервис его уже использует, он нативен для кода;Spark и Python уже умеют его использовать «из коробки»;можем передать в код клиента схему с описанием структур;не нужно поддерживать код самого биндинга.
• если это JSON, то сервис его уже использует, он нативен для кода;
• Spark и Python уже умеют его использовать «из коробки»;
• можем передать в код клиента схему с описанием структур;
• не нужно поддерживать код самого биндинга.

Минус — есть дополнительные расходы на упаковку-распаковку, но и быстрые парсеры тоже есть. На этом варианте мы и остановились.

Минимальный биндинг изнутри

Чтобы было проще разобраться, я подготовил демо-проект со следующей структурой:

Основная идея проекта:

• Собрать shared библиотеку с С-интерфейсом.
• Добавить к ней Python-биндинг с использованием ctypes.
• Упаковать в переносимый пакет (Wheel), готовый для установки в любое окружение для платформы.

Бекэнд-код на Go

Демо-код бэкенд-логики содержит вложенные структуры и код, который их принимает и возвращает — это максимально типичная ситуация в реальной жизни. Структуры уже размечены для JSO- генератора — это необязательно.

Экспортируем функции и структуры через C Call интерфейс

Как видно, всё, что делает код — это принимает и возвращает строки с JSON. Для описания структур используется JSON Schema. Это не идеальный вариант — из-за ограниченности типов JSON больше демонстрация возможности использовать рефлекшены для создания схемы.

Собираем всё в разделяемую библиотеку

Обёртка на Python

Используем ctypes с динамической загрузкой собранной библиотеки.

И не забываем про сборку проекта в пакет:

Всё, что нужно — Python и установленный poetry. При запуске сборки poetry build собирает пакеты source и wheel. Пакет wheel как раз и предназначен для дистрибьюции бинарных зависимостей для Python.

PEX как контейнер, и деплой кода на кластер

Любой PySpark скрипт с python-udf перед тем, как начать выполнять план запроса на кластере, производит сериализацию функции и всех обьектов из её контекста через библиотеку cloudpickle. То есть, для того, чтобы восстановить функцию на кластерных пайтон-воркерах нужно обеспечить действительность всех ссылок из pickle.

Существует несколько способов деплоя Python окружения на кластер:

1. Устанавливать библиотеки в окружение системного Python.

• Плюс: просто сделать.

• Минусы:сложно синхронизировать и следить за всеми артефактами.невозможно работать и отлаживать несколько разных окружений, а использование venv только всё усложняет;сложно отследить, какие версии использовались в определенный момент.
• сложно синхронизировать и следить за всеми артефактами.
• невозможно работать и отлаживать несколько разных окружений, а использование venv только всё усложняет;
• сложно отследить, какие версии использовались в определенный момент.

1. Использовать docker/kubernetes.

• Плюс: можно сделать любое окружение.
• Минус: не подходит для bare-metal инсталляций с Hadoop

1. Деплой через EGG.

• Минус: работает только с нативным Python-кодом — не получится использовать биндитнги из-за ограничений zipimport.
• Плюс: работает из коробки, не нужно паковать всё окружение, если библиотека самодостаточна

1. Использование законсервированных окружений в виде conda-pack, venv-pack, pex.

• Плюсы:разово собирается и пакуется окружение, не получится испортить.прозрачно деплоится на кластер, но нужно оркестрировать установку на все тачки.возно версионировать синхронно с основным кодом.
• разово собирается и пакуется окружение, не получится испортить.
• прозрачно деплоится на кластер, но нужно оркестрировать установку на все тачки.
• возно версионировать синхронно с основным кодом.
• Минус: PEX-пакет весит как полноценный virtualenv.

Мы используем динамическую версию из Git в виде комбинации тега, майлстоуна, хеша коммита и признака dev-ветки.

Для себя мы выбрали PEX как наиболее зрелый вариант пакета. Если коротко, то это self-extacted virtualenv, упакованный в обычный zip и снабжённый бустстап-секцией для поиска хост-интерпретатора.

Для использования PEX как интерпретатора Python на кластере нужно модифицировать настройки Spark. У нас конфигурация контекста выглядит примерно так:

Для сборки PEX-пакета достаточно самой утилиты pex и списка всех пакетов, которые должны быть в него установлены:

Естественно, что в PEX-пакете должен находится pyspark, иначе Spark не сможет запустить Python-воркеры на кластерных машинах.

Включаем нашу UDF в работу

Подразумевается, что Spark-сессия запущена, настроена и используется PEX.

Чтобы дальше оперировать со структурами в привычном виде, описываем схему сообщения в формате Spark и используем коробочную функцию from_json.

Что почитать по теме

• Туториал по CGo;
• документация к ctypes;
• PySpark Package Management.

Вот, кстати, несколько интересных материалов о Golang:

• Как написать производительный и безопасный backend на Go
• Оператор Kubernetes на Go и Kubebuilder для начинающих
• 7 must-have книг для Go-разработчиков

PaaS в Авито: 2500 сервисов, на которых нужно было реализовать авторизацию, и ничего не сломать

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

В PaaS есть UI-интерфейс — дашборд. В нём находится всё для управления сервисами. Например:

• деплой в разные окружения;
• информация о потреблении ресурсов;
• задеплоенные манифесты в Kubernetes;
• связи: в какие другие сервисы ходит этот сервис и откуда приходят запросы к нему.

Ещё у нас есть собственный формат для межсервисного взаимодействия — brief. Он похож на Protobuf, но немного упрощённый и заточенный под наши требования.

Пример брифа:

Похоже на protobuf, но только гораздо проще. Это значит, потребуется немного времени на погружение и вход.

Вот, как команды используют Brief:

1. Разработчики пишут brief-схемы для сервиса, описывают ручки, которые хотят сделать.
2. Затем они используют генератор, который на нужном языке программирования генерит код сервера и клиента
3. Остается только реализовать логику внутри ручек или использовать клиенты для походов в другие сервисы
4. При деплое brief-схемы регистрируются в отдельном реестре

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

Наши требования к межсервисной авторизации

Чтобы понять, каким будет наше решение для межсервисной авторизации, мы опросили команды сервисов, живущих внутри PaaS, поговорили с отделом безопасности, и выявили шесть требований:

1. Контролировать доступ к ручкам. Часть сервисов или отдельные ручки могут содержать чувствительную информацию: данные пользователей или финансовые показатели.
2. Логировать изменения. Нужно знать, кто и когда вносил изменения и пользовался ручками, — это основа любой системы безопасности.
3. Не сломать связи 2.500 сервисов. Нарушение любой из связей могло привести к деградации продакшена.
4. Не менять сервисы. Сервисов много, поэтому заставлять сотни разработчиков вносить изменения в свои сервисы — неправильно.
5. Не повлиять на скорость работы. Для некоторых сервисов лишние 10мс — уже критично.
6. Сделать платформенное решение. Некоторые команды уже стали пилить свою локальную авторизацию: например, через JWT-токены. Нам нужно было централизованное и удобное решение, подходящее всем.

Проанализировав требования, мы стали думать, как продуктово организовать конфигурацию политик авторизации.

Конфигурация политик авторизации. Как это выглядит для пользователя

У нас уже был подход конфигурации как код. В каждом сервисе есть файлик app.toml, на основании которого наша платформа катит сервис так, как это нужно разработчикам:

• с нужным количеством реплик;
• с нужными переменными окружения;
• с указанным расписанием запуска кронов;
• и многое другое.

Формат при этом максимально абстрагирован от инфраструктурных деталей и прост в использовании.

Политики конфигурируются через файл auth.toml — по аналогии с app.toml. Вот почему мы решили так сделать:

• разработчики уже привыкли к toml;
• можно логировать и апрувить изменения через git и настройки codereview;
• можно использовать канареечное тестирование;
• разработчикам не нужно погружаться в реализацию.

Структура auth.toml состоит из двух разделов: default и policy. Они позволяют задать общие правила и конкретизировать их для отдельных ручек.

Политик может быть несколько. Главное — не повторять ручки, ни внутри политики, ни внутри всего auth.toml, чтобы избежать наложений. Это контролирует наш валидатор.

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

Какие типы клиентов существуют:

• сервисы — сервисы внутри PaaS.
• пользователи — логин одного сотрудника (например, user:apgubarev) или целый юнит (например, user.unit:architecture).
• внешние зависимости (например, ext:pass-bot).

Генерация auth.toml происходит через утилиту auth init. Мы встроили её в свой внутренний CLI. Она позволяет не переписывать все ручки из брифа в auth.toml вручную и не допускать ошибок.

Утилита берёт потребителей из реестра, о котором я писал выше, и добавляет их в секцию default. Дальше разработчик может донастроить auth.toml через отдельные policy.

Также auth init добавляет в файл auth.toml мини-документацию, которая позволяет быстро вспомнить, какие разделы за что отвечают.

В итоге для пользователя вся конфигурация политик происходит в одном файле auth.toml. Всё остальное делаем мы.

Техническая реализация

У нас было два основных варианта, как сделать межсервисную авторизацию.

1. Запилить middleware для используемых языков. Но у такого решения есть ряд проблем:

– реализации на разных ЯП будут различаться и поддержка усложняется кратно количеству библиотек

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

– инфраструктурный слой протекает в сервисы — концептуально плохо.

2. Реализовать авторизацию на базе service mesh.

+ нет проблем, свойственных первому решению.

+ нагрузка только на команду PaaS, пользователям авторизации ничего делать не нужно.

В итоге мы остановились на service mesh на Istio. До Istio у нас было самописное решение, но сейчас Istio отвечает всем нашим потребностям — правда, приходится платить сложностью. Но это уже отдельная история.

Подробнее про Istio →

Основной принцип любого service mesh — перехват входящего трафика и заруливание на сайдкар.

1. В каждый под, где нужен service mesh, добавляется сайдкар.
2. Трафик приходит в сайдкар.
3. Из сайдкара трафик проксируется в сервис.

Обратно — аналогично. Сервис шлет трафик не напрямую, а через прокси.

Аутентификация через mTLS

Прежде чем реализовывать авторизацию, нужно узнать имя клиента. Для аутентификации мы используем mTLS. Он уже был реализован у нас ранее для:

• шифрования чувствительных данных. Трафик даже внутри кластера может быть небезопасным, поскольку там работает куча сторонних библиотек.
• защиты от несанкционированного доступа. Например, по IP пода. Чтобы постучаться в сервис, в mTLS нужен персональный сертификат. Сервис может управлять доступами, используя имена этих сертификатов.

Подробнее про использование mTLS в Авито можно почитать в статье моего коллеги.

Автоматизация выдачи сертификатов

TLS-сертификаты для доступа к сервисам можно выдавать вручную, но лучше — генерировать их автоматически. Для автоматизации выдачи сертификатов мы используем готовое решение — Spire.

Spire на GitHub →

Spire реализует стандарт SPIFFE, который описывает подход к идентификации и управлению секретами в инфраструктуре. Spire состоит из двух частей:

• Сервер — отвечает за выпуск новых сертификатов.
• Агент — выдает сертификаты.

Вот, как работает автоматизация выдачи сертификатов с помощью Spire:

1. Сервер выпускает новые сертификаты.
2. Агент запускается на каждой ноде.
3. Istio конфигурирует сайдкар так, чтобы он устанавливал соединения с другими сайдкарами по протоколу mTLS.
4. Istio конфигурирует envoy: где и как он может получать сертификаты.
5. Сайдкар приходит к указанному агенту и получает TLS-сертификат, с помощью которого шифрует трафик.

Подробнее про Spire и SPIFFE можно почитать в статье моего коллеги.

HTTP-фильтр

Istio в качестве сайдкара использует envoy. Внутри envoy запрос проходит через цепочку фильтров и идет в целевой порт внутри пода, если его не заблокировал один из HTTP-фильтров. В Istio много готовых фильтров, но можно написать и свои.

ext-authz спрашивает у некоего внешнего агента (можно подложить сюда что угодно, хоть самопис), можно ли запросу лететь дальше. Если запрос блокируется, envoy сразу отвечает кодом 403. До сервиса запрос даже не доходит.

В качестве внешнего агента мы используем готовое и проверенное решение – Open Policy Agent.

Open Policy Agent

Open Policy Agent (OPA) — это CNCF-дипломированный проект, направленный на унификацию применения политик в различных технологиях и системах. Одно из назначений OPA — как раз service mesh. Плюс есть много готовых интеграций, в их числе — envoy.

Подробнее про Open Policy Agent →

OPA может работать в двух вариантах: как демон, или как Go-библиотека. В обоих случаях агенту можно передавать политики на языке Rego и данные в формате JSON.

Rego — это собственный декларативный язык OPA для выражения политик над сложными иерархическими структурами данных.

Особенность Rego в том, что он позволяет описывать сложные политики сокращённым синтаксисом — буквально в одно выражение. Для нас это было полезно, поскольку в поддержке можно очень быстро «продебажить» код глазами, даже не открывая IDE.

Другие плюсы Rego:

• читабельность. Например, прогон многомерного массива в Rego можно сделать так: sites[].servers[].hostname.
• расширяемость. Поскольку Rego написан на Golang, в него легко добавлять свои плагины: например, для похода во внутренние API или БД.
• удобное тестирование и дебаг. Например, можно сравнивать политики двух сервисов на совместимость.

Документация Rego →

Перевод auth.toml в Rego

В нашей схеме разработчики описывают политики в auth.toml. А наша задача перевести этот конфиг на Rego, чтобы его понимал Open Policy Agent.

Вот, как мы реализовали перевод auth.toml в rego всего в пару сотен строк кода.

1. Общая часть. Забираем нужные входные данные, определяем тип клиента, устанавливает значения по умолчанию (например, allow = false).

2. Проходим по политикам в auth.toml. Если хоть одна из политик разрешает запрос, открываем доступ.

Итоговая схема

Подытожим, как работает межсервисная авторизация.

1. Запрос попадает на сайдкар.
2. Сайдкар спрашивает у агента, можно ли пустить запрос дальше.
3. Агент обрабатывает rego-правила и решает, нужно ли блокировать запрос.
4. Если запрос блокируется, клиент получает 403. Если нет — запрос доходит до сервиса.

Проблема: latency запросов к OPA

После реализации авторизации через запрос к сайдкару мы замерили latency. Оказалось, что envoy тратит дополнительные 10 мс для походов в OPA.

Для нагруженных сервисов это критично — им нельзя добавлять больше 2 мс. Поэтому для них такой latency стал бы блокером для использования авторизации.

Мы выяснили, что тратили время на одинаковые запросы к OPA. Ведь для пользователя apgubarev авторизационный ответ для ручки getUser будет одним и тем же на протяжение всей жизни пода (помним — политики меняются только при новом деплое).

Решение — кешировать. Envoy позволяет писать расширения разными способами, но нам лучше всего подошел Lua. Теперь запрос один раз посылается агенту, сохраняется в памяти и больше туда не ходит, если не было изменений в auth.toml. Прибавка — не больше 1 мс.

Валидация изменений в политиках авторизации

Недостаточно просто включить межсервисную авторизацию, нам было важно ничего не сломать. И у нас получилось.

Представим ситуацию: у сервиса A есть ручка getUser, на которую ходит сервис B. Владелец сервиса A закрывает доступ к этой ручки через auth.toml — сервис B ломается, получаем деградацию продакшена.

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

— Предотвращаем закрытие существующих связей.

— Проверяем корректность auth.toml: указанные клиенты существуют, одна ручка указана только один раз и т.д.

— Не допускаем в прод с ошибками — блочим деплой.

Ещё мы завели реестр auth.toml. У нас уже был сервис схем для Brief, с помощью которого мы проверяли, что изменения не ломают обратную совместимость ручки или не удаляют поле, которое кто-то использует.

Перед деплоем сервиса мы достаём связи из реестра и тестируем rego правила: проверяем зависимости и клиентов.

Проверка зависимостей происходит следующим образом:

1. Смотрим зависимости в brief-папке.
2. Берём rego зависимостей из прода.
3. Тестируем rego с данными текущего сервиса: передаём путь и клиента, убеждаемся, что пришёл положительный ответ.

Проверка клиентов выглядит так:

1. Смотрим зарегистрированные клиенты у сервиса.
2. Берём текущий rego сервиса.
3. Проверяем доступ у клиентов: передаём путь и клиента, убеждаемся, что доступ есть.

Если билд падает, мы делаем одно из трех:

1. Оставляем связь как есть — наткнулись на связь, которая реально нужна, разработчикам нужно договориться, что с ней делать.
2. Помечаем связь как deprecated — связь уже устарела, нужно поставить задачу, чтобы её выпилить.
3. Ничего не делаем — нашли ненужную связь.

Таким образом нам удалось не допустить поломок существующих связей. До сих пор не было ни одного инцидента связанного с этим.

Выводы

Что у нас получилось

• Простое платформенное решение для межсервисной авторизации. auth.toml не требует погружения, разработчики сразу начинают писать политики.
• Сервисы не затронуты. Ничего менять не нужно, достаточно добавить ещё один файлик конфигурации.
• Связи не сломаны. Все валидаторы отрабатывают корректно, пока не было ни одного инцидента.

Что поняли

Просто добавить авторизацию недостаточно. Как минимум нам ещё понадобилась генерация auth.toml и валидаторы для контроля изменений.

Что нам дали Open Policy Agent и rego

• Не надо писать и поддерживать своё решение.
• Понятная и читаемая политика для платформенной команды.
• Удобная работа с оргструктурой, включая все иерархические вложенности.
• Возможность тестирования доступов.

Полезные ссылки:

• Статья «Платформа как сервис в Авито: как это устроено» на Хабре.
• Статья «Поддержка mTLS в своём Service Mesh: чему мы научилиcь» на Хабре.
• Официальный сайт Istio.
• GitHub-репозиторий Spire.
• Официальный сайт Open Policy Agent.
• Документация Rego.

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

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

В этой статье я покажу бенчмарки нескольких самых популярных форматов сериализации в языке Golang и расскажу про преимущества и недостатки каждого из них. Это поможет вам выбрать подходящий формат для вашего проекта с учетом его потребностей. Например, меньший размер сериализованных, если вы хотите сэкономить место при хранении данных или сетевые ресурсы при их передаче, время сериализации/десериализации, если для вашего приложения критична скорость и т. д.

Какие бывают форматы сериализации

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

Бинарные форматы

Avro, Protobuf, CBOR и Msgpack относятся к бинарным форматам сериализации данных. Ключевые различия между ними:

• Схема данных:Avro поддерживает схемы данных, которые описывают структуру сериализованных данных. Это позволяет легко изменять схему данных и делает его подходящим для развивающихся схем данных.Protobuf также использует схемы данных и автоматически генерирует код на основе схемы. Это позволяет легко создавать и обновлять структуру данных.CBOR и Msgpack не предоставляют встроенной поддержки схем данных, поэтому данные сериализуются без дополнительной информации о структуре.
• Avro поддерживает схемы данных, которые описывают структуру сериализованных данных. Это позволяет легко изменять схему данных и делает его подходящим для развивающихся схем данных.
• Protobuf также использует схемы данных и автоматически генерирует код на основе схемы. Это позволяет легко создавать и обновлять структуру данных.
• CBOR и Msgpack не предоставляют встроенной поддержки схем данных, поэтому данные сериализуются без дополнительной информации о структуре.
• Человекочитаемость:Бинарные форматы не предназначены для чтения человеком, однако Avro и Protobuf можно сериализовать в json. Это может быть полезно в целях дебага, но мало пригодно для production среды.
• Бинарные форматы не предназначены для чтения человеком, однако Avro и Protobuf можно сериализовать в json. Это может быть полезно в целях дебага, но мало пригодно для production среды.
• Компактность и производительность:CBOR и Msgpack более компактны и имеют лучшую производительность при сериализации и десериализации данных, поскольку сериализованные сообщения не содержат метаданных.Avro и Protobuf также обеспечивают хорошую компактность и производительность, но процесс сериализации и десериализации может быть более сложным из-за схемы данных. Например, в случае с avro во время сериализации проводится анализ схемы, чтобы впоследствии определить каким образом обрабатывать то или иное поле.
• CBOR и Msgpack более компактны и имеют лучшую производительность при сериализации и десериализации данных, поскольку сериализованные сообщения не содержат метаданных.
• Avro и Protobuf также обеспечивают хорошую компактность и производительность, но процесс сериализации и десериализации может быть более сложным из-за схемы данных. Например, в случае с avro во время сериализации проводится анализ схемы, чтобы впоследствии определить каким образом обрабатывать то или иное поле.
• Эволюционность:Avro и Protobuf обеспечивают поддержку обратной совместимости при изменении схем данных. Это облегчает эволюцию данных в распределенных системах.CBOR и Msgpack не предоставляют встроенной поддержки для эволюции данных и требуют дополнительных усилий при изменении структуры данных. Например, потребуется изменить поведение обрабатывающей логики при удалении полей из структуры сообщения, сериализованного в одном из этих форматов.
• Avro и Protobuf обеспечивают поддержку обратной совместимости при изменении схем данных. Это облегчает эволюцию данных в распределенных системах.
• CBOR и Msgpack не предоставляют встроенной поддержки для эволюции данных и требуют дополнительных усилий при изменении структуры данных. Например, потребуется изменить поведение обрабатывающей логики при удалении полей из структуры сообщения, сериализованного в одном из этих форматов.

Текстовые форматы

JSON (JavaScript Object Notation) и XML (Extensible Markup Language) — два разных текстовых формата для сериализации и обмена данными. Вот ключевые различия между ними:

• Синтаксис:JSON использует более легкий и компактный синтаксис для представления данных — в виде пар «ключ:значение». Структура данных обычно более краткая и простая.XML использует размеченный синтаксис с использованием открывающих и закрывающих тегов, что делает его более развернутым и многословным.
• JSON использует более легкий и компактный синтаксис для представления данных — в виде пар «ключ:значение». Структура данных обычно более краткая и простая.
• XML использует размеченный синтаксис с использованием открывающих и закрывающих тегов, что делает его более развернутым и многословным.
• Удобочитаемость:JSON-документы человек может легко читать и понимать благодаря простому синтаксису.XML также человекочитаем, но его сложнее интерпретировать из-за многочисленных тегов и атрибутов.
• JSON-документы человек может легко читать и понимать благодаря простому синтаксису.
• XML также человекочитаем, но его сложнее интерпретировать из-за многочисленных тегов и атрибутов.
• Размер данных:JSON-документы обычно имеют меньший размер по сравнению с XML благодаря компактному синтаксису.XML-документы обычно более объемные и занимают больше места.
• JSON-документы обычно имеют меньший размер по сравнению с XML благодаря компактному синтаксису.
• XML-документы обычно более объемные и занимают больше места.
• Поддержка данных:JSON поддерживает ограниченное количество данных-типов, включая строки, числа, булевы значения, массивы и объекты.XML позволяет создавать собственные структуры данных с использованием DTD или XSD и может представлять более сложные структуры.
• JSON поддерживает ограниченное количество данных-типов, включая строки, числа, булевы значения, массивы и объекты.
• XML позволяет создавать собственные структуры данных с использованием DTD или XSD и может представлять более сложные структуры.
• Валидация:JSON обычно не имеет встроенной системы валидации, поэтому она может потребовать дополнительных инструментов.XML поддерживает валидацию данных с использованием DTD или XSD.
• JSON обычно не имеет встроенной системы валидации, поэтому она может потребовать дополнительных инструментов.
• XML поддерживает валидацию данных с использованием DTD или XSD.

Бенчмарки: сравниваем форматы сериализации между собой

Для этой статьи мы выбрали самые известные форматы: Avro, Protobuf, Msgpack, XML, CBOR и несколько известных библиотек для работы с JSON

Тестирование проводилось на ПК с такими характеристиками: Apple M1 Pro 3.2 GHz 10 cores (8 performance and 2 efficiency), 32 GB LPDDR5, APPLE SSD AP0512R.

Всего проводились замеры данных трех разных объемов:

• 1 строка
• 100 строк
• 100 000 строк

Использовались только целочисленные, только строковые и смешанные (строки+числа) данные. Все поля nullable с разной степенью заполненности. Размер сериализованных данных измерялся только для 100 000 строк, поскольку на 1 или 100 строках результат мог бы получиться недостаточно репрезентативным.

Ниже на отдельных диаграммах показаны время сериализации и десериализации и объем полученных данных для каждого формата.

Исходники можно увидеть здесь.

1 строка

Целые числа

Строковые данные

Смешанные данные

100 строк

Целые числа

Строковые данные

Смешанные данные

100 000 строк

Целые числа

Строковые данные

Смешанные данные

Плюсы и минусы каждого формата

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

Json

+ в golang довольно шустро работает по сравнению с бинарными форматами сериализации, особенно это заметно на больших объемах текстовых данных;

+ человекочитаемый формат данных;

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

- система типов не поддерживает из коробки decimal, datetime, enum и прочие полезные типы, имеющиеся в других форматах сериализации (например, enum в protobuf);

- размер сериализованных данных значительно больше, чем в любом бинарном формате;

XML

+ человекочитаемый формат;

+ XSD (xml schema) позволяет парсеру не только проверить правильность синтаксиса документа, но также и его структуру, типы данных и модель содержания;

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

- xml использует явные открывающие и закрывающие теги, а так же атрибуты, что добавляет дополнительные символы, в связи с этим сообщения получаются довольно многословными (исторические причины, по которым xml выглядит именно так, кратко описаны здесь);

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

Cbor

+ быстрая (де)сериализация и маленький объем сериализованных данных в сравнении с текстовыми форматами сериализации;

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

- не человекочитаемый формат;

Msgpack

+ быстрая (де)сериализация и маленький объем сериализованных данных в сравнении с текстовыми форматами сериализации;

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

- не человекочитаемый формат;

Avro

+ есть поддержка как бинарного, так и в текстового форматов, что может быть полезно, например при работе в тестовой среде;

+ схема данных описывается в json-формате, за счет полей в схеме достигается backward и forward compatibility;

- avro во время сериализации проводит анализ схемы, чтобы впоследствии определить каким образом обрабатывать то или иное поле, это оказывает негативный эффект на время сериализации;

Protobuf

+ быстрая (де)сериализация и маленький объем сериализованных данных в сравнении с текстовыми форматами сериализации;

+ схема данных описывается в .proto файлах, на основе которых генерируются объекты в необходимом вам языке. С помощью описанных в схеме полей достигается backward и forward compatibility (с oneof есть нюансы);

- не человекочитаемый формат;

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

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

Предыдущая статья: Повышение качества данных с использованием Zero Bug Policy

Влад Гайденко, ментор Эйч Навыки и бэкенд разработчик в Авито, где он с командой разрабатывает платформу «Гарантии запчастей» в рамках Авито Авто, расскажет, как применять TDD без стресса и писать код, который не будет ломаться.

Что такое TDD

TDD (Test-Driven Development) часто считается крайне сложным подходом, но на самом деле все довольно просто. Представьте, что вы строите дом: вы же сначала нарисуете план, и только потом начнете строить, верно? В TDD все работает точно так же, только с кодом: сначала мы пишем тесты, описывающие, как должен работать наш код, а потом уже пишем сам код, чтобы эти тесты проходили.

Другими словами, здесь полностью меняется логика разработки: обычно мы пишем код, потом тестируем и финалим баги. В TDD все идет от обратного — схема примерно такая:

1. Определяем функциональность, которую нужно реализовать. Условно: вам нужно при запросе «300» возвращать «спартанцев».
2. Под эту функциональность пишем тест — в нем вы описываете, как должна работать будущая программа. Спойлер: при запуске тест провалится, потому что тестировать пока нечего.
3. Пишете самый простой (даже «глупый») код, после которого тест просто перестанет выдавать ошибку.
4. Если тесты больше не падают, поздравляем, вы великолепны. Теперь можно делать рефакторинг кода и пилить «по красоте».

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

Почему TDD работает

Давайте разберем на конкретном примере. Представьте, что мы разрабатываем функционал расчета стоимости доставки. Начав с написания тестов, мы сразу видим важные моменты:

• Как считать стоимость для разных типов товаров (легких, тяжелых и хрупких)
• Как учитывать расстояние до адреса доставки
• Как применять скидки и акции

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

Что это реально дает

Когда начинаешь работать с TDD, понимаешь, насколько это мощный инструмент. Ниже о его суперсилах.

Надежды как швейцарские часы

Допустим, через какое-то время нам нужно добавить новый тип доставки — курьером. Без тестов мы бы постоянно переживали: «А вдруг что-то сломалось?» С тестами же мы можем спокойно вносить изменения, зная, что если что-то пойдет не так, тесты нас предупредят.

Актуальная документация

Тесты становятся отличной «живой» документацией. Новый разработчик в команде? Просто покажите ему тесты, и он быстро поймет, как все работает. Это намного удобнее, чем читать многостраничные документы, которые часто устаревают.

Экономят время на поиске багов

Помните ситуации, когда нужно срочно исправить ошибку, а вы не знаете, где искать? С TDD все проще: написал тест, воспроизводящий проблему, исправил код, убедился, что тест проходит — и готово!

Где TDD реально полезен

Отлично подходит для:

• Бизнес-логики: все эти CRUD-операции, валидации, обработка ошибок — самое то!
• Утилитных модулей: математические операции, форматирование данных, работа с коллекциями

Где лучше подумать дважды:

• Интеграция с внешними сервисами
• Работа с файлами и сетью
• Настройка окружения

С чего начинать TDD

Освоить TDD действительно несложно, но начинать нужно не с кода, а с правильной постановки задач в системе управления проектами, например, в Jira.

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

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

• Моторные масла с типом акциз до 5 л включительно объема доступны для доставки
• Тип доставки «Лошадью»
• Логистическая компания «Рога и копыта»

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

Когда задача сформулирована с критериями приемки, разработчик вместе с QA-инженером могут начать создавать тест-кейсы прямо в Jira. Эти тест-кейсы будут отражать различные сценарии использования, которые должны быть протестированы.

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

1. Проверить, что типы товара доступны для доставки в «Лошадью» в «Рога и копыта»:

• моторные масла
• с акцизой
• объем (1, 2, 5 л)

2. Проверить, что типы товара недоступны для доставки «Лошадью» в «Рога и копыта»:

• моторные масла
• без акцизы
• объем (1, 2, 5 л)

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

Очень важно, чтобы тест-кейсы, определенные в Jira, просматривались на встречах по оценки задач (PBR). Это позволяет:

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

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

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

Как писать тесты еще лучше

Используйте принцип «Светофора»:

• Красный: пишете тест, он падает
• Зеленый: пишете код, тест проходит
• Рефакторинг: улучшаете код, тесты все еще зеленые

Делайте тесты читаемыми:

• Давайте понятные названия
• Структурируйте код теста
• Используйте вспомогательные функции для часто повторяющихся действий

Вот пример плохого теста:

Здесь неясно, что конкретно проверяет тест. Название теста ничего не говорит, а использование магических чисел усложняет понимание. Это приводит к путанице, особенно если тесты придется читать или модифицировать спустя время.

А вот хороший пример:

Почему это хороший пример?

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

Типичные сложности и как с ними справиться

«Это же долго!»

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

«Не знаю, с чего начать»

Начните с простого! Возьмите небольшую задачу и попробуйте написать для нее тесты. Используйте существующие тесты как примеры. Постепенно вы найдете свой стиль и ритм.

«У нас legacy-код»

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

Подготовка проекта

Например, в Go есть отличные инструменты для тестирования. Я рекомендую:

• Стандартный пакет testing для базового функционала
• Testify — набор полезных ассертов и мок-объектов, лично используем на проекте
• Ginkgo — BDD-стиль написания тестов
• Встроенные инструменты для измерения покрытия кода:

TDD — это не какая-то магия, а просто удобный инструмент, который помогает писать более качественный код. Начните с малого, и вы увидите, как постепенно ваш код становится надежнее, а работать над проектом — приятнее.

Удачи в практике TDD! А если у вас остались вопросы — велком в комменты.

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

Массивы и слайсы

Начнём с базовых концепций:

• Массив — последовательность элементов определённого типа и фиксированной длины. Это неизменяемая структура данных и его capacity всегда равна его длине.
• Слайс — своеобразная надстройка поверх массива с возможностью изменения длины.

Распространённые ошибки при работе со слайсами

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

Про длину и capacity слайсов стоит помнить две вещи:

1. Когда мы создаём новый слайс, его длина равна его capacity, если не указано другое.
2. Как именно растет вместимость слайса начиная с версии go 1.20.

Поскольку в Go все аргументы передаются в функции по значению, то при передаче слайсов в качестве аргумента передаётся значение его структуры. Иными словами, копируется только ссылка на массив, на основе которого построен слайс. Сам массив со всеми содержащимися в нём данными не копируется. Если этого не знать, можно получить неожиданный результат.

Дальше рассмотрим примеры.

Перевыделения памяти под новый массив

Здесь в main объявлен слайс, состоящий из одного нуля. После чего этот слайс передаётся в функцию с говорящим названием changeSliceValues. Там с ним происходят некие действия, в текущем примере в нулевой индекс записывается единица. Если в main вывести слайс на экран до и после вызова функций, то ожидаемо увидим [0] и [1] соответственно.

Теперь немного изменим пример — в changeSliceValues после записи в нулевой индекс с помощью append добавим в конец слайса 2, после чего запишем в нулевой индекс 3. И несмотря на применённые нами изменения, принты в main все так же выведут [0] и [1]. Размер слайса не изменился, несмотря на то, что мы добавили append. Вторая запись тоже не применилась.

На самом деле всё станет понятно, если вспомнить озвученные ранее факты о слайсах и структуру слайса. В самом начале мы создали слайса с длинной, которая равна его capacity, то есть единице.

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

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

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

Копирование слайсов

С этой же проблемой можно столкнуться, если попытаться скопировать слайс.

В примере в переменную newSlice с помощью слайсинга копируются данные из оригинального слайса, в том числе и указатель на массив с данными. При выполнении append данные перетираются в оригинальном массиве, потому что newSlice указывает на оригинальный массив из первого слайса.

В Go есть специальная встроенная функция copy, которая позволит безопасно копировать любые слайсы.

На картинке выше видно, что, использовав copy, мы перенесли элементы из исходного слайса в новый. Теперь можно безопасно делать append, не боясь перетереть изначальные данные.

Работа со строками и рунами

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

В бесконечном цикле мы получаем новые новости, после берём первые сто рун и отдаём в некую функцию storeArticlePreview, которая заботится о том, чтобы сохранить руны в кэш.

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

Кстати, почему в этом примере мы скастили строку к массиву рун, прежде чем брать от неё первые 100 символов? Покажу на примере, чем отличаются руны от байтов.

Берём стандартную строку Hello World и делаем отдельную переменную с рунами. По задумке хотим запринтить первые пять символов, то есть слово Hello.

Если посмотреть на вывод, то не в нем не будет ничего необычного. Сначала принтятся сами руны, потом, когда мы конвертируем это в строку, выводится слово Hello. Когда берём первые пять элементов от строки, снова выводится Hello.

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

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

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

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

Часто можно просто кастить строчку к слайсу рун и работать уже с ним. Но не стоит забывать про оверхэд, который мы можем получить в этом случае. На каждую строчку будут существовать две переменные: одна из них хранит исходную строку, а вторая — массив рун. Если строк много и они длинные, это также может иметь значение. К счастью, в Go есть процессорные оптимизации, которые в определенных ситуациях позволяют его избежать.

Каналы

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

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

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

Теперь попробуем ответить на вопрос: «зачем закрывать канал?». Для этого обратимся к документации: «отправитель может закрыть канал, чтобы указать, что значения больше не будут отправляться». Если отправитель закрывает канал, значит это может понадобится кому-то, кроме него — например, читателю канала. Рассмотрим пример, когда это может быть полезно:

Здесь есть говорящая функция writeToChan, в которой происходит запись в канал и в main цикл по этому каналу — в нём мы высчитываем значения. Если не закрыть канал, цикл никогда не закончится и случится deadlock. Если закрыть — for range успешно завершается и логика программы идёт дальше.

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

time.After

Раз уж обсудили каналы, поговорим о структурах, которые используют каналы. Одна из них — time.After. Это функция возвращает канал, который закроется после заданной задержки времени. Она обычно используется для создания таймеров или установки таймаутов на выполнение определенной логики в программах.

Вот пример, где мы обрабатываем какие-то события, которые поступают из некой очереди. Если за 15 минут мы не встретили ни одного события в канале, то кинем warning, что что-то случилось.

Если запустить код, он будет рабочим. Но если вдруг есть какой-то дашборд, в котором мы измеряем потребление памяти и событий большое число, то мы легко обнаружим, что есть утечка памяти. При среднем потоке в миллион сообщений в 15 минут утечка составит порядка 200 Мб. Один канал Go весит около 200 байт. Получается, что на каждое событие убегает новый канал.

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

Обращаемся к документации: «таймер не будет собран сборщиками мусора до тех пор, пока он не отработает». То есть time.after, который мы ставили на 15 минут, на это время остаётся висеть мертвым грузом, даже если он уже не находится в области видимости.

Горутины

Горутина — это лёгкий поток выполнения в userspace, пока потоки операционной системы живут в kernel space. Горутины управляются средствами Go, а потоки — средствами операционной системы.

Горутины спроектированы так, чтобы быть более эффективными, чем традиционные потоки операционной системы. Но у них тоже есть несколько ловушек, в которые можно попасть при работе.

В примере ниже мы создаём слайс из цифр от 1 до 5 и горутины в цикле, и в каждой из них прибавляем своё число из слайса к переменной sum. Можно подумать, что в выводе будет число 15, то есть сумма чисел от 1 до 5 — однако это не так.

Здесь проблема состоит в замыканиях — функциях, которые захватывают переменные из внешней области видимости. В примере анонимная функция, которая создаётся в цикле, является замыканием, потому что она захватывает переменную value из внешней области видимости.

Особенность их работы в том, как используется захваченная переменная. Горутины не захватывают значения переменных на момент их создания — они захватывают ссылку на переменную. Поэтому, когда горутины начинают выполняться, цикл зачастую уже прошёл, и переменная value имеет последнее значение из слайса. По нему мы итерируемся, хотя гарантии того, что цикл завершится раньше, чем начнёт работу одна из горутин — нет. Это приводит к тому, что в переменной sum оказывается не значение 15.

Это настолько распространённая проблема, что мейнтейнеры Go решили изменить семантику переменных цикла for, чтобы предотвратить их непреднамеренное использование в замыканиях и горутинах на каждой итерации. В версии 1.21 появился соответствующий эксперимент, а с версии 1.22 эта проблема уже полностью перестала воспроизводиться. Но, поскольку версия 1.22 свеженькая, и ещё не все успели обновиться, берите себе на заметку эту особенность работы замыканий.

Пакеты sync и atomic

В примерах выше мы использовали sync WaitGroup, чтобы дождаться выполнения горутин и, кстати, сделали это неправильно. Признавайтесь, кто не заметил?) Стоит обратить внимание на то, где мы делаем wg.Add, и подумать, чем это черевато.

Давайте разбираться. Посмотрим на устройство wait group:

В структуре WaitGroup из интересного мы видим семафор и некий noCopy. Сначала поговорим про семафор, а точнее про то, что по сути WaitGroup — это простенькая обёртка над семафором с тремя методами:

1. .Add(delta int) увеличивает значение семафора на переданное значение.
2. .Done() уменьшает значение семафора на единицу.
3. .Wait() блокирует выполнение до тех пор пока значение семафора не станет равно 0.

Так вот, проблема — в запущенных нами горутинах заключается в том, что нет гарантии, что они запустятся до того, как будет вызван .Wait. Это значит, .Wait может завершиться до выполнения .Add. Поскольку гарантии порядка запуска горутин нет, в итоге мы рискуем неверно решить, что все горутины завершили работу, хотя некоторые её ещё даже не начали.

Теперь вернёмся к структуре WaitGroup и присмотримся к полю noCopy, с таким же типом noCopy — что же это такое? По названию можно догадаться, что это что-то, что нельзя копировать, подобное поле есть в большинстве структур пакета sync. Давайте посмотрим, что же произойдёт, если всё же скопировать структуру с этим полем. Для примера будем использовать мьютекс, в нем также есть поле noCopy с типом noCopy.

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

На структуре Counter определены два метода: один увеличивает значение определенного ключа на единицу, другой — сразу на переданное значение. Есть мейн, в котором мы инициализируем структуру счётчика и запускаем две горутины для увеличения значения одного и того же ключа, делаем слип, чтобы дождаться выполнения горутин, и принтим значения, которые окажутся в мапе нашего счётчика. Но вот принт, к сожалению, мы так и не увидим, потому что упадём с паникой.

Проблема с кодом в том, что всякий раз, когда вызывается increment, в него копируется наш Counter c, поскольку increment определён на типа Counter, а не на *Counter. Другими словами, это value receiver, а не pointer receiver. Следовательно, increment не может изменять оригинальную переменную типа Counter, которую мы создали в main. Поэтому при каждом вызове increment происходило копирование счётчика со всем его содержимым, в том числе и мьютексом.

А теперь вспомним, что мьютекс — это просто обёртка над семафором, и, когда мы его копируем, мы копируем и семафор. При этом копия и оригинал могут жить своими отдельными жизнями, и ничто не помешает им конкурировать за операции с одним и тем же блоком памяти. Поэтому копирование мьютекса неправильно.

Так вот, за счет того самого noCopy есть возможность пометить любую структуру как невозможную к копированию (многие структуры из пакета sync так и отмечены). Тогда с помощью команды go vet можно будет обнаружить места, в которых отмеченная структура копируется, и найти потенциальную проблему в коде своего приложения.

Atomic

Теперь перейдем к ещё одному распространённому примитиву синхронизации — атомикам. Они предоставляют возможность безопасного доступа к общей памяти для операций чтения, записи и модификации переменных. Кроме того, в общем случае операции с атомиками быстрее, чем операции с мьютексом, за счёт использования специального набора процессорных инструкций. Однако, с этим преимуществом приходит и недостаток, про который периодически забывают: операции с атомиками атомарны по отдельности, но не атомарны все вместе.

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

defer

defer позволяет отложить выполнение блока кода до окончания функции, в которой он был вызван. Обычно он используется для обеспечения освобождения ресурсов, например, закрытия файла или разблокировки мьютекса, независимо от того, как функция завершает работу — из-за обычного возврата, паники или ошибки.

Здесь мы видим структуру профиля и несколько возможных типов для него, а также метод GetBalance(), в котором, в зависимости от типа профиля, выбирается тот или иной метод подсчета баланса. Допустим, теперь мы хотим добавить лог с итоговым балансом, полученным при подсчёте:

И в результате добавленного нами лога мы всегда будем видеть запись «profile balance: 0». Почему так?

Давайте внимательнее посмотрим на то, что написано про defer в документации языка: «The arguments to the deferred function (which include the receiver if the function is a method) are evaluated when the defer executes, not when the call executes». Значение аргументов для функции в defer (в том числе и ресивер метода) вычисляются в момент исполнения defer, а не в момент исполнения функции. В нашем примере на момент исполнения defer в переменной balance у нас по дефолту лежит 0 — вот с этим значением наш принт и выполняется. А для того, чтобы достичь результата, который мы и хотели получить, то есть для того, чтобы в принте фигурировала итоговая сумма расчета, можно использовать концепцию, с которой мы уже встречались — замыкания.

Анонимная функция не имеет никаких аргументов, переменная balance расположена в теле этой функции. Соответственно, будет сохранена ссылка на эту переменную, и фактическое значение будет получено при выполнении анонимной функции по сохранённой ссылке.

Интерфейсы

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

У нас есть интерфейс реквестера, который делает какой-то запрос и в респонсе отдает int — допустим, статус-код нашего запроса. Есть конкретный тип concrete requester, который реализует интерфейс реквестера. Ещё для интерфейса реквестера есть функция, которая позволяет его инициализировать в зависимости от переданного значения value.

Если оно больше нуля, то мы возвращаем instance concret requester’а. Если оно меньше или равно нулю — просто возвращаем не проинициализированную переменную. В main есть логика, которая сначала принтит реквестер, а затем делает ещё один принт в зависимости от того, nil он или нет.

Если запустить программу, то мы увидим забавный вывод:

Мы получили реквестер nil, но при этом он не nil.

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

Под капотом есть две структуры для интерфейсов: eface для пустого и iface, если определён набор методов, которым должен соответствовать тип. Сейчас нас интересуют общие для них поля — а именно тип данных, которые реализует интерфейс, и ссылка на область в памяти, где находится его значение. Для того, чтобы две переменные интерфейс-типа были равны, нужно чтобы у них были равны оба этих поля.

Теперь посмотрим

что именно лежит в этих полях для нашей переменной requester:

Ага! Вот отсюда ноги и растут. Несмотря на то, что фактическое значение у переменной — это nil, тип таковым не является, что и приводит к тому, что сравнение requester == nil — это false.

Это поведение связано с так называемым value boxing и заслуживает отдельной статьи, которая уже в общем-то и так любезно написана здесь.

Особенности вендоринга

Представим, что вы завели библиотеку на Go, в которой должны происходить какие-то сетевые запросы. Внутри этой библиотеки вы реализовали некий клиент, который умеет делать запросы, получать в респонсе какие-то данные и отдавать их в виде структур, описанных в папке models.

Теперь попробуем использовать эту библиотеку в каком-нибудь сервисе. Добавили её в go.mod, прописали в консоли go mod tidy, go mod vendor, решили заглянуть в vendor, а там, неожиданно лежит только часть файлов и папок вашей библиотеки.

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

“The go mod vendor command constructs a directory named vendor in the main module”s root directory containing copies of all packages needed to build and test packages in the main module.”

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

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

На этом все! Напишите в комментариях, есть ли ещё какие-то ошибки, о которых не рассказал в статье? Обсудим их в следующий раз!

Я — Даниил Динько, веду свой личный телеграм-канал, где рассказываю о себе, об IT и о Golang, а также являюсь экспертом и спикером в компании Эйч Навыки, TeamLeadом в компании-лидере в международном кибербезе, ex. старшим разработчиком в Ozon Tech. Разбираемся, как четко оценивать задачи, как использовать инструменты для повышения точности планирования и на что обращать внимание в коде и архитектуре, чтобы не допустить скрытых ошибок.

Как подходить к оценке задач на Go (и не только)

1. Понимание бизнес-цели

Первая задача — разобраться в бизнес-ценности задачи. Это критически важно. Если я понимаю, как задача влияет на бизнес и какие цели она преследует, то дальше процесс становится логичнее.

2. Оценка масштаба и сложности

Я анализирую, насколько сложна задача и насколько она совпадает с моей зоной ответственности:

• Если задача близка моему профилю, я быстро схватываю суть.

• Если в команде есть специалист, который лучше разбирается в этой теме (например, коллега Вася), есть два пути: первый — передать ему задачу с вводными, второй — консультироваться, если Вася занят.

У нас в команде, как и в Озоне, часто бывает, что такой «Вася» один на 10 человек. И если он ещё и не слишком общительный, то тут не остаётся ничего, кроме как искать альтернативы: спрашивать на созвонах, разбираться в коде, погружаться в дебаг и изучать продукт самостоятельно. Это дольше, но работает, а Вася потом на ревью укажет на потенциальные минусы.

3. Классификация задачи

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

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

Производительность и масштабируемость — еще одни важные аспекты, но с ними на старте всё не так просто.

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

4. Нефункциональные требования

• RPS (Requests Per Second) — сколько запросов в секунду выдерживает система?
• Latency — какая допустимая задержка?
• Uptime — уровень доступности в процентах (например, 99.9%).

Часто бизнес не понимает технические термины, поэтому уточняю показатели через DAU (ежедневные активные пользователи), MAU (ежемесячные активные пользователи) и специфику продукта.

На основе этих данных принимается решение:

• Сделать MVP и быстро запустить, чтобы протестировать гипотезу.
• Проработать масштабируемое решение, если проект требует высокой стабильности.

В 98% случаев мы выбираем MVP. Это нормально. Глубокое продумывание архитектуры — редкость на старте, если только проект не требует стабильности с первых дней.

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

Какие библиотеки и инструменты использовать

Для задач с хайлоадом выбор технологий и подходов критически важен. На рынке много готовых решений, но в реальных проектах, особенно в таких компаниях, как Ozon, часто создаются кастомные библиотеки и прослойки для решения конкретных задач. Причина проста: стандартные инструменты не всегда выдерживают требуемые нагрузки.

Популярные инструменты для хайлоад-систем:

Базы данных:

• PostgreSQL — классика для реляционных данных
• Redis/Memcached — быстрые key-value хранилищ
• ClickHouse — аналитическая база для больших объёмов данных
• ScyllaDB, CockroachDB — новые решения, которые набирают популярность благодаря своей производительности и масштабируемости.

Микросервисные архитектуры:

Используется Transactional Outbox — паттерн, позволяющий сохранять атомарность между базой данных и очередью сообщений.

Выбор инструмента всегда зависит от специфики задачи. Если речь идёт о BigData или финтехе, то ключевые критерии выглядят так:

• Отказоустойчивость: чтобы система не падала.
• Атомарность: операции либо выполняются полностью, либо откатываются.
• Консистентность: все узлы системы видят одно и то же состояние данных, без рассинхрона.

Чтобы сделать атомарность и консистентность, используют две таблицы в PostgreSQL: основная таблица с данными и outbox для задач, которые нужно передать в следующий этап.

Как это работает:

• В таблице outbox собираются записи для отправки в топик.
• Воркер обрабатывает данные из таблицы и передаёт их в топик.
• Это гарантирует, что состояние базы и очереди сообщений синхронизированы.

Монолит против микросервисов:

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

• Если система монолитная: достаточно транзакций в реляционных базах данных, что упрощает работу.

• Если BigData: переход на микросервисы становится необходимым, но вызывает сложности с консистентностью и отказоустойчивостью.

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

О производительности и оптимизации

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

Если у вас микросервисная архитектура, начните с анализа трейсов:

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

У вас нет трейсов в большой микросервисной архитектуре? Тут могу выразить только одно — мои искренние соболезнования, поскольку в вашем случае предстоит знатно пострадать, чтобы определить, в чём проблема.

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

Материалов по профилированию на Go — миллион. Если вкратце:

• Используйте встроенные инструменты профилирования Go (pprof, trace).
• Обратите внимание на сборщик мусора (GC) — он может отнимать слишком много времени.
• Проверьте наличие утечек горутин.

Что касается трендовых инструментов, Redis Streams обретает все большую популярность. Redis Streams — это основа для построения своего быстрого in-memory брокера сообщений с кастомными алгоритмами ретраев, крутой интеграцией с key/value Redis, а это возможность сделать пуш в стрим и изменение значения по ключу атомарными. Если говорить более глобально, сейчас постоянно растет количество решений в DevOps, облаках, MlOps. Да и Go постепенно набирает обороты — каждая новая версия языка обычно приносит улучшения в производительности компилятора и стандартной библиотеки.

Какие есть риски при оценки задач

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

Часто оценки разработчиков позитивные, причём чем меньше грейд, тем позитивнее сроки. К примеру, из сеньоров в моей команде приходится выдавливать сроки, просто так они не скажут. Если удалось получить сроки, то они будут на всякий случай умножены в 2.5-3 раза — и это отчасти правильно.

Почему так происходит? Ответ — подводные камни. Предугадать их заранее сложно, даже теоретически. Это объясняет, почему сеньоры завышают сроки, а мидлы, напротив, обещают сделать всё «завтра», а потом либо перерабатывают, либо просят перенести сроки.

Как минимизировать риски

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

2. Тестируйте новые технологии: не доверяйте только хорошим отзывам — ваш кейс может оказаться нестандартным. Всегда проводите локальные тесты перед внедрением.

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

4. Будьте готовы к изменениям: изменения бизнес-требований — частое явление. Знания команды о продукте могут не совпадать с реальной спецификой.

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

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

6. Что важно описать для багов:

1. Проблему и путь её воспроизведения.
2. Текущее поведение системы.
3. Ожидаемое поведение.
4. Идеи для решения (если они есть).

Как выстраивать командную работу

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

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

Чтобы избежать такого, важно:

• Давать каждому возможность работать в своей зоне ответственности. Это прокачивает навыки и уверенность.
• Периодически поручать задачи вне их основной зоны, чтобы снизить бас-фактор (критическая зависимость от конкретного человека).

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

Об изменениях в управлении Go-проектами

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

Что изменилось в последние пару лет:

1. Проектов на Go становится всё больше. Это касается и хайлоад-компаний, и стартапов.
2. Растёт популярность языка среди разработчиков. Конкуренция за рабочие места увеличивается, зарплаты немного снижаются, хотя они всё ещё остаются одними из самых высоких на рынке бэкенда.
3. Сложность найма. Найти хорошего мидла стало чуть проще, но с сеньорами всё по-прежнему сложно.

Если ты сеньор, то, несмотря на то, что у тебя вакансия абсолютно везде скрыта, тебе всё равно будут стабильно писать раз в неделю, находя твои контакты через слитые базы.

Советы тимлидам, которые начинают с Go

1. Примите, что найм будет сложным. Если вы не в бигтехе, без хорошего нетворка тяжело быстро нанять нужных специалистов.
2. Балансируйте задачи и созвоны. У разработчиков должно оставаться достаточно времени на фокусную работу. В среднем, это 4 часа в день. Старайтесь не перегружать команду митингами.
3. Снижайте бас-фактор. Следите, чтобы каждый разработчик периодически выполнял задачи вне своей основной зоны ответственности.
4. Не будьте диктатором. Обсуждайте задачи на грумингах, вовлекайте команду в процесс принятия решений. Это повышает их вовлечённость и улучшает качество решений.
5. Давайте ответственность, а не только задачи. Если пытаться тащить всё на себе, можно выгореть.
6. Заставляйте тестировать код локально. Даже если это сложно, практика локального тестирования сильно снижает вероятность багов.
7. Используйте бюджеты на обучение. Развивайте хардовые навыки команды, чтобы повысить их эффективность.

Для новичков в Go

Если возникают трудности, самое очевидное решение — спрашивать у коллег. Но что делать, если боишься надоесть вопросами?

1. Найди ментора. Это платный, но удобный вариант для вопросов, не связанных с продуктом.
2. Если вопрос связан с продуктом, обращайся к разработчику, который в нем разбирается.
3. Если он отвечает «ну посмотри в код», используй дебаггер и локальные тесты, чтобы собрать информацию.

Дебаггер — это must-have. Если его нет, тестируй на тестовом или staging-окружении. Если нет и их — проблема не в тебе, а в процессе CI/CD.

Стоит пойти и мягко намекнуть или спросить, а вот как тестировать? Потому что в таком кейсе только на проде тестить, но это совсем ненормально.

Что еще поможет?

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

Несколько полезных ресурсов

YouTube-каналы:

HighLoad Channel

Golang Channel

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

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

Вместе с экспертами Kursfinder я рассмотрела более 50 программ обучения и отобрала для вас 25 лучших курсов по Golang, бесплатных и платных. Еще больше вариантов вы можете найти в каталоге курсов по Go.

ТОП-10 лучших курсов по Golang в 2026 году

1. Go-разработчик с нуля от «Яндекс Практикума» — онлайн-курс с большими объемами практических заданий для новичков.
2. Golang Developer. Professional от OTUS — продвинутая программа для карьерного роста.
3. Продвинутый Go‑разработчик от «Яндекс Практикума» — обучение с персональными консультациями от ментора.
4. Онлайн-курс Go-разработчик от «Брунояма» — экспресс-курс с проектной работой для быстрого освоения базы.
5. Backend-разработчик на Go от Skillfactory — углубленный курс обучения для новичков с тремя разными тарифами.
6. Golang Developer. Basic от OTUS — базовая программа для быстрого входа в профессию.
7. Golang-разработчик от «Слёрма» — углубленный онлайн-курс со сквозным проектом для опытных.
8. Уроки Golang от itProger — недорогая программа для освоения основ.
9. Golang для инженеров от «Слёрма» — интенсивная программа по созданию микросервисов на Go для инженеров.
10. Онлайн-практикум Golang-разработчик. Basic от Rebrain — большой набор практики в асинхронном формате.

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

Онлайн-курсы по Golang

1. Go-разработчик с нуля | Яндекс Практикум

Онлайн-курс Golang-разработчика от Яндекса. В ходе обучения вы создадите портфолио, поработаете с настоящими заказчиками, познакомитесь с реальными рабочими задачами, разовьете софт-скилы. После прохождения курса вас ждет диплом о профессиональной переподготовке (при наличии среднего или высшего профессионального образования) или сертификат, а также помощь в трудоустройстве.

• Стоимость: от 19 500 рублей в месяц в рассрочку на 8 месяцев.
• Длительность: 8 месяцев.
• Формат обучения: теоретические материалы, практика, работа над проектом, тренажеры, фидбэк от опытных разработчиков.
• Сертификат: диплом о профессиональной переподготовке или сертификат.

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

Преимущества:

• практика с первого дня;
• поддержка со стороны опытных разработчиков;
• работа с реальными заказчиками;
• проекты для портфолио;
• активное комьюнити;
• помощь с поиском работы.

Недостатки:

• короткие сроки рассрочки с высокими платежами;
• вся теория предоставляется в текстовом виде.

Программа обучения:

• Основы Go.
• HTTP в Go и REST API.
• SQL и базы данных.
• Многопоточность.
• Linux.
• CI/CD и Docker.
• Подготовка к трудоустройству.

Ознакомиться с полной программой >>>

2. Golang Developer. Professional | OTUS

Углубленная программа от Otus, рассчитанная на опытных разработчиков, которые хотят дорасти до уровня middle и senior. Вы освоите не только синтаксис языка, но и важнейшие внутренние механизмы, узнаете переводить проекты с других стеков на язык Go. Большое внимание уделяется решению практических задач, углублению знаний языка и сопутствующих технологии.

• Стоимость: от 12 100 рублей в месяц в рассрочку на 10 месяцев.
• Длительность: 5 месяцев.
• Формат обучения: лекции с преподавателями, теоретические материалы, работа над проектом, самостоятельные работы.
• Сертификат: сертификат о прохождении курса.

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

Преимущества:

• проектная работа;
• «живое» общение с экспертами;
• возможность посетить бесплатные вебинары и оценить особенности обучения на платформе;
• размещение резюме в базе OTUS;
• прохождение собеседований у партнеров;

Недостатки:

• для поступления требуется пройти вступительное тестирование;
• время проведения вебинаров — вторник и четверг в 20:00 по Москве (может быть неудобным для жителей некоторых регионов России).

Программа обучения:

• Начало работы.
• Concurrency.
• Стандартные библиотеки и практики.
• Сеть и базы данных.
• Микросервисы.
• Проекты.

Ознакомиться с полной программой >>>

3. Продвинутый Go‑разработчик | Яндекс Практикум

Курс обучения Golang с трудоустройством от Яндекса, рассчитанные на специалистов с опытом в бэкенде. Он позволит вам получить необходимые навыки для роста до уровня middle-специалиста. В программу курса включено углубленное изучение языка, решение задач и встречи 1-на-1 с ментором. В ходе обучения вы пройдете прикладные темы, создадите 3 учебных проекта для портфолио. После окончания курса слушателям выдается диплом о профессиональной переподготовке или сертификат (в зависимости от имеющегося уровня образования).

• Стоимость: от 26 000 рублей в месяц в рассрочку на 6 месяцев.
• Длительность: 6 месяцев.
• Формат обучения: теоретические материалы, практика, проект, тренажеры, поддержка от команды.
• Сертификат: диплом о профессиональной переподготовке или сертификат.

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

Преимущества:

• возможно обучение с дедлайнами или без;
• 12 персональных консультаций с ментором;
• помощь в обучении от YandexGPT;
• три проекта для портфолио;
• возврат денег за обучение, если устроитесь разработчиком в «Яндекс» в течение шести месяцев после выпуска;
• помощь с поиском работы и развитием на текущем месте;
• вебинары для разбора сложных тем, сессии Q&A;
• программа разработана на основе требований работодателей.

Недостатки:

• высокие платежи по рассрочке или кредит;
• много уроков в текстовом формате.

Программа обучения:

• Пакеты стандартной библиотеки.
• Конкурентность.
• Промежуточный проект.
• Паттерны проектирования.
• Тулинг.
• Расширенная стандартная библиотека.
• Алгоритмы и структуры данных.

Ознакомиться с полной программой >>>

4. Онлайн-курс Go-разработчик | Бруноям

🎁Используйте эксклюзивный промокод «kursfinder», чтобы получить скидку 15% на любой курс школы.

Интенсивный онлайн-курс Golang для начинающих, который позволит изучить особенности языка программирования в короткие сроки. Вы научитесь решать все задачи, которые возникают перед Junior-разработчиком, погрузитесь в паттерны проектирования. В курсе предусмотрены 2 дополнительных модуля по Linux и Agile, которые пригодятся в работе. В конце обучения вас ждет работа над финальным проектом с защитой и презентацией.

• Стоимость: от 4 158 рублей в месяц в рассрочку на 12 месяцев.
• Длительность: 3 месяца.
• Формат обучения: видеоматериалы, воркшопы, практика, вебинары.
• Сертификат: сертификат о прохождении курса.

Кому подойдет: новичкам, которые хотят получить уверенную базу для начала разработки на Go.

Преимущества:

• мини-группы по 10-12 человек;
• преподаватели с опытом в сфере от 3-х лет;
• 72 часа практической работы;
• скидка за раннюю оплату;
• помощь центра карьеры;
• 2 дополнительных модуля: Linux и Agile;
• возврат суммы в течение месяца после оплаты, если курс не понравился.

Недостатки:

• только 1 проектная работа;
• достаточно короткий курс.

Программа обучения:

• Основы языка.
• REST API.
• Git.
• Работа с базами данных.
• Многопоточность.
• Архитектура приложения.

Ознакомиться с полной программой >>>

5. Backend-разработчик на Go | Skillfactory

Программа этого курса программирования Go делится на три варианта обучения: базовый, оптимальный и VIP. В зависимости от выбранной опции вы получите разные объемы индивидуальных консультаций, а также дополнительные курсы. Например, в оптимальном доступен курс «Английский для IT», а в VIP — «Английский для IT» и «Алгоритмы и структуры данных». 80% обучения состоит из практических задач.

• Стоимость: от 3 959 рублей в месяц в рассрочку на 36 месяцев.
• Длительность: 12 месяцев.
• Формат обучения: лекции в формате видео, живые вебинары, практика.
• Сертификат: диплом о профессиональной переподготовке или сертификат.

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

Преимущества:

• фокус на подготовке к трудоустройству;
• оперативная помощь от менторов и координаторов;
• 3 проекта для портфолио;
• большой набор дополнительных материалов;
• доступ к курсу и обновлениям навсегда;
• помощь с трудоустройством;
• дополнительная скидка при единовременной оплате;
• 3 тарифа на выбор.

Недостатки:

• редкий старт программы;
• высокая стоимость VIP тарифа.

Программа обучения:

• Программирование на Go.
• Алгоритмы и структуры данных.
• Многопоточность.
• Инструменты разработчика.
• Работа с базами данных.
• Продвинутый Go.
• Архитектура и основы DevOps.

Ознакомиться с полной программой >>>

6. Golang Developer. Basic | OTUS

Базовая программа курса Go-разработчика от Otus, которая позволит быстро войти в IT или сменить основной рабочий язык разработки. Обучение проходит в онлайн-формате при непрерывном взаимодействии с преподавателями. Большие объемы практических заданий и работа над выпускным проектом позволят не только освоить все необходимые материалы, но и хорошо закрепить полученные знания.

• Стоимость: от 6 800 рублей в месяц в рассрочку на 10 месяцев.
• Длительность: 5 месяцев.
• Формат обучения: вебинары, практика и проектная деятельность.
• Сертификат: сертификат о прохождении курса.

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

Преимущества:

• недорогой курс;
• «живое» общение с экспертами;
• можно 1 раз бесплатно перейти в другую группу;
• доступна оплата за счет работодателя;
• удобный личный кабинет;
• можно посетить бесплатные вебинары и оценить особенности обучения на платформе;
• активное комьюнити.

Недостатки:

• короткий срок рассрочки — всего 10 месяцев.
• время проведения вебинаров — понедельник и среда в 20:00 по Москве (может быть неудобным для жителей некоторых регионов России).

Программа обучения:

• Знакомство с Go.
• Синтаксис языка.
• Алгоритмы и структуры данных.
• Concurrency.
• Решение типовых задач.
• Промышленная разработка.

Ознакомиться с полной программой >>>

7. Golang-разработчик | Слёрм

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

• Стоимость: от 15 000 рублей в месяц в рассрочку на 4 месяца.
• Длительность: 3,5 месяца.
• Формат обучения: набор источников с теорией, онлайн-встречи с экспертом, практика, проектная деятельность.
• Сертификат: сертификат о прохождении курса.

Кому подойдет: специалистам уровня Junior, которые пишут на Go, а также программистам middle-уровня, которые работают с другими языками не менее двух лет. Кроме того, курс пригодится разработчикам, которые хотят переписать сервисы на Golang.

Преимущества:

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

Недостатки:

• редкий старт программы;
• небольшие объемы курса — 52 часа практики и 11 часов теории.

Программа обучения:

• Вводный курс в Go.
• Основные концепции.
• Конкурентная обработка данных.
• Интерфейсы и работа с ошибками.
• Тесты.
• Context.
• Проектная работа.

Ознакомиться с полной программой >>>

8. Уроки Golang | itProger

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

• Стоимость: от 700 рублей в месяц — стоимость подписки на 1 месяц.
• Длительность: 9 уроков и 30 заданий.
• Формат обучения: видеоуроки, текстовые материалы, домашние задания с проверкой и комментариями.
• Сертификат: нет.

Кому подойдет: новичкам без опыта работы с Go, которые хотят создать свой первый проект.

Преимущества:

• недорогой курс с возможностью проходить обучения на других программах по подписке;
• задания к каждому уроку;
• доступны консультации с экспертом (не во всех тарифах);
• оперативная работа службы поддержки.

Недостатки:

• узкоспециализированный курс;
• мало практики.

Программа обучения:

• Внедрение в язык Go.
• Отслеживание URL.
• Создание структур.
• Работа с HTML.
• Подключение SQL.
• Новостной сайт.
• Добавление данных через сайт.
• Динамические страницы.
• Публикация проекта на сервер.

Ознакомиться с полной программой >>>

9. Golang для инженеров | Слёрм

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

• Стоимость: от 12 500 рублей в месяц в рассрочку на 4 месяца.
• Длительность: 11 недель.
• Формат обучения: видеоуроки, онлайн-встречи, практика, проектная деятельность.
• Сертификат: сертификат о прохождении курса.

Кому подойдет: DevOps-инженерам, которые хотят автоматизировать разработку. Системным администраторам, которые хотят стать DevOps-инженерами. Разработчикам, желающим научиться работать с микросервисной архитектурой.

Преимущества:

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

Недостатки:

• жесткие дедлайны;
• редкий набор студентов на потоковое обучение.

Программа обучения:

• Основы Golang.
• Concurrency.
• Практика.
• Docker.
• Kubernetes.
• Финальный проект.

Ознакомиться с полной программой >>>

10. Онлайн-практикум Golang-разработчик. Basic | Rebrain

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

• Стоимость: 60 000 рублей или рассрочка от банка.
• Длительность: 30+ заданий.
• Формат обучения: теоретические материалы, практика, поддержка команды в закрытом чате.
• Сертификат: нет.

Кому подойдет: разработчикам, специалистам по тестированию, системным архитекторам, DevOps-инженерам и системным аналитикам.

Преимущества:

• доступ навсегда;
• регулярное обновление программы;
• 90% практики;
• асинхронное обучение.

Недостатки:

• рассрочка только через банк;
• не выдается сертификат.

Программа обучения:

• Основы языка.
• Модули и пакеты.
• Структуры и интерфейсы.
• Асинхронность.
• Тестирование.
• Кодогенерация.

Ознакомиться с полной программой >>>

Бесплатные курсы по Go/Golang

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

1. Основы Go — Яндекс Практикум

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

Главное о курсе:

• материалы можно изучать в комфортном темпе;
• подходит для развития в Go-разработке.

2. Разработка веб-сервисов на Golang (Go) — Stepik

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

Главное о курсе:

• актуальная программа;
• плавное погружение в тему.

3. Введение в Go-разработку — Skillbox

Программа представляет собой вебинар в записи. Лекции от ведущих экспертов школы длительные и насыщенные, материал преподается без «воды». Авторы рассматривают перспективы и сферу применения Golang, рынок труда разработчиков и особенности создания различных ПО.

Главное о курсе:

• для изучения не требуется регистрация;
• насыщенная программа.

4. Программирование на Golang — Stepik

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

Главное о курсе:

• предусмотрена выдача сертификата;
• есть обратная связь от экспертов.

5. Курс Go: онлайн обучение с нуля, бесплатно — Code Basics

Бесплатный курс, который становится доступен после процесса регистрации. Помимо теоретического материала, для слушателей подготовлена практика в браузере. Эксперты познакомят слушателей с коллекциями, строками, функциями и методами начиная с основ.

Главное о курсе:

• большой упор на практику;
• для изучения материалов требуется минимум времени.

6. Go (Golang) — первое знакомство — Stepik

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

Главное о курсе:

• предусмотрена выдача сертификата;
• доступная подача для новичков.

Видеоуроки по Golang

• Golang Developer. Professional от OTUS — уроки в формате видеолекций от экспертов крупнейшей IT-школы России. Слушателям предлагаются подробные разборы проектов, возможных подводных камней и «ловушек» на собеседованиях. Программа ориентирована на опытных разработчиков.
• Разработка & Язык Go от Максима Жашкевича — подборка видеоуроков для новичков. Лекции обучения Golang с нуля небольшие и в то же время насыщенные.
• Курс разработчика Golang от Uproger — на канале автора представлено большое количество уроков, связанных с программированием на Go. Эксперты расскажут, как установить Golang и решать с его помощью различные задачи.
• Изучаем Golang от ThisIsIT — небольшие и доступные видеоуроки по Golang. Для лучшего понимания автор транслирует запись с экрана и подробно описывает каждое действие. Эксперт познакомит учеников с функциями, циклами, указателями, методами и др.
• Программирование на Go от VK Team — подборка насыщенных лекций, подготовленная российским IT-сообществом. Насыщенная программа подходит для опытных программистов, желающих освоить Go. Слушатели смогут познакомиться с функциями, структурами, моделями и др.
• Уроки по Golang от The Art of Development — подборка представляет собой полноценный курс Go разработки. В уроках есть не только теоретическая составляющая, но и практическая: эксперт расскажет, как решать задачи, связанные с написанием и запуском веб-сервера на разных типах ОС.
• Программист из 80х / История появления интернета и программирования в СССР / Всё о Go — от «АйТиБороды» — видеоурок в формате интервью с экспертом, который расскажет не только о кодировании на Go, но и об истории развития интернета. Урок можно считать введением в Golang, эксперты рассказывают об особенностях, преимуществах и недостатках языка программирования.
• Podlodka #240 — Golang от Podlodka — видеоурок представляет собой длительную лекцию по Golang. Эксперты расскажут об истории языка программирования, углубятся в область применения, а также поделятся рекомендациями для написания чистого кода.
• Архитектура Go проекта на практике от Evrone Development — обучение Golang в понятной и наглядной лекции. Эксперт расскажет, как подбирать практики для построения архитектуры и написания кода. Кроме того, уделяется внимание основным моментам, связанным с написанием кода на Go. Для удобства изучения материала лекция разделена на тайминги.

Полезные ресурсы

• SQL Tutorial от W3Schools — на площадке размещено подробное руководство по SQL. Пособие будет полезно в самостоятельном изучении любого языка программирования, в том числе и Golang.
• Официальный тур по Go от Go.dev — на платформе представлены небольшие уроки для обучения языку Golang. В правом окне есть небольшой тренажер для отработки полученных навыков. Энциклопедия доступна на нескольких языках, однако русского в перечне нет, что может вызвать определенные затруднения с изучением материала.

Бесплатные тренажеры и задачи по Golang/GO-разработке

• Timus Online Judge — на сайте размещены задачи в разделе «архив». Также желающие могут поучаствовать в онлайн-соревнованиях, приводящиеся на базе УрФУ.
• Codewars — на платформе представлен функциональный тренажер, а также есть сообщество программистов, которые помогут в освоении новых языков программирования. Упражнения для отработки представлены в формате «ката», с ними можно освоить более профессиональные техники кодирования или научиться одному из 55 доступных языков программирования.
• Exercism — онлайн-тренажер, ориентированный на работу более, чем с 70 языками программирования, в том числе и Golang. Для работы не требуется загрузка языка: тренажер поддерживает его, поэтому учиться можно прямо в браузерной версии. Функция автоматического анализа решений укажет на возможные ошибки в коде. Кроме того, ученики могут получать обратную связь от наставников.

Заключение

На hh.ru представлено почти 500 вакансий Go-разработчика с зарплатой от 55 000 рублей. При этом большая часть вакансий — около 400 — предлагает более высокий уровень дохода — от 145 000 до 325 000 рублей и выше. Язык программирования Go, или Golang, является одним из самых перспективных и высокооплачиваемых, поэтому он будет интересен как новичкам в IT, так и опытным разработчикам, которые хотят увеличить свой доход. Освоить этот язык можно в короткие сроки на курсах Go, представленных в нашей подборке. Мы рассмотрели платные и бесплатные онлайн-программы, а также полезные видеоуроки для повторения теории и тренажеры, которые пригодятся для отработки знаний на практике.

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

Цифровизация экономики и импортозамещение — два тренда, которые были с нами в 2023–2025 годах и останутся в 2026. Особенно это касается ниш, связанных с разработкой ПО, автоматизацией и работой облачных инфраструктур.

Java, Python, Go и Rust активно применяются в этих нишах. Но рынок в 2026 году преподнёс сюрпризы: Go неожиданно упал в рейтинге TIOBE, оставшись при этом самым высокооплачиваемым языком в России. Разберём, что происходит с каждым языком и на чём стоит писать. В этой статье сравниваем Go, Rust, Java и Python по рейтингам TIOBE и GitHub, зарплатам и реальному применению — чтобы вы точно знали, на чём стоит писать в 2026 году.

Go упал с 7-го на 16-е место в TIOBE, но остаётся самым высокооплачиваемым языком в РФ (320 000 руб.)

Python — первый по TIOBE (21,25%), второй на GitHub

Java опустился на 4-е место в TIOBE, но стабильно растёт на GitHub (+20,73%)

Rust за пределами топ-10 TIOBE, но занял прочные позиции в системном программировании

TypeScript впервые обогнал Python на GitHub Octoverse 2025

Java: преимущества и недостатки для разработки в 2026 году

Java за почти 30 лет своего существования прошёл большой путь, оброс огромной экосистемой и стал стандартом индустрии в области автоматизации. В 2026 году Java опустился на 4-е место в рейтинге TIOBE (7,99%, минус 2,37 п.п.), уступив C и C++. Но на GitHub Octoverse 2025 он показал рост +20,73%, оставшись четвёртым по количеству активных репозиториев. Рассмотрим этот язык подробнее.

Кстати, если вам интересно обучение этому языку программирования, то рекомендуем онлайн-курс «JAVA-разработчик» от EdMe.pro.

Краткая история Java и его популярность в корпоративной среде

Java разработала и выпустила в 1995 году компания Sun Microsystems для программирования бытовой электроники. В итоге получился производительный язык с понятным синтаксисом и революционной фишкой в виде портативности. Java можно запустить на любом устройстве. Благодаря этому он хорошо зарекомендовал себя в сервисах автоматизации и прочно укрепился в корпоративной среде.

В 2010 году Oracle приобрела Sun Microsystems и продолжила развитие Java. Язык используется для разработки серверных программ, веб и android-приложений, а также в системах с высокими нагрузками.

Сейчас на нём работают Яндекс Маркет, Ozon, сервисы Google, Netflix, Amazon и другие крупные инфраструктуры.

Сильные стороны: обширная экосистема, поддержка многопоточных приложений, JVM

Обширная экосистема

Согласно рейтингу TIOBE за март 2026 года, Java занимает 4-е место с долей 7,99%. Хотя это ниже, чем годом ранее, Java остаётся одним из самых используемых языков в мире.

На GitHub Octoverse 2025 Java занял 4-е место и показал рост +20,73% по количеству активных репозиториев. Это подтверждает, что корпоративная экосистема Java продолжает развиваться.

Такая популярность соизмерима и с его экосистемой. У Java за годы разработки скопилось более сотни фреймворков под разные задачи. А ещё это один из немногих языков, у которого есть стеки фреймворков — несколько фреймворков, которые объединены в одну экосистему.

Здесь есть решения под работу с вебом, разработку приложений, обучение нейросетей и много чего ещё.

Поддержка многопоточных приложений

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

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

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

JVM — виртуальная машина

Разработчики языка Java старались придерживаться принципа: «Написал один раз, запускай везде». Для этого они создали виртуальную машину — программу, которая имитирует работу компьютера. Она компилирует Java в байт-код, который может запускаться на разных устройствах.

У этого подхода следующие преимущества:

• Не надо заморачиваться со сборкой мусора, JVM сделает всё сама;
• Java код не нужно переписывать под каждую платформу;
• Быстрое выполнение часто используемых методов, так как они компилируются в машинный код и кешируются;
• Безопасность. Весь код выполняется на изолированной от основной среды виртуальной машине.

Почему Java медленно развивается и требует много ресурсов

Сравнительно медленное развитие

Медленное развитие Java связано в первую очередь с его огромным наследием. Java 23 — последняя стабильная версия языка, но многие компании работают на Java 11 и Java 8, которым уже много лет. При обновлении языка разработчики вынуждены сохранять высокий уровень совместимости со старыми версиями, что тормозит процесс развития.

Но он всё же развивается. Компания Oracle выпускает новые промежуточные версии Java каждые полгода и каждые 3 года готовит долгосрочные версии, поддерживаемые до 3 лет.

Высокая ресурсоёмкость

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

• Java использует сборщик мусора, который иногда останавливает выполнение программы для освобождения неиспользуемой памяти. Это может приводить к задержкам и большему потреблению ресурсов.
• Виртуальная машина является посредником между реальным устройством и кодом. Как итог, этот «посредник» нуждается в дополнительных ресурсах.
• Необходимость совместимости между различными версиями языка усложняет оптимизацию приложений, что также влияет на их производительность.

Преимущества и недостатки Python: почему он такой удобный и медленный

Python известен как один из самых дружелюбных языков программирования, особенно для начинающих разработчиков. В марте 2026 года он занимает 1-е место в рейтинге TIOBE (21,25%), хотя и потерял 2,59 п.п. за год. На GitHub Octoverse 2025 Python стал вторым, уступив TypeScript, но показав рост +48,78%. За этой простотой скрываются как значительные преимущества, так и ограничения в производительности.

Почему Python такой простой и гибкий

У Python лаконичный и читаемый синтаксис. Вот так выглядит вывод «Hello world!» в Python:

А так в Java:

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

При разработке на Python не надо заморачиваться с низкоуровневыми задачами, его можно запускать на разных платформах. У Python за годы сформировалось большое комьюнити, много сторонних библиотек, и он подходит для решения разных задач — от веб-разработки до создания Android-приложений и обучения ИИ.

Почему Python доминирует в области науки о данных, искусственного интеллекта и веб-разработки

Согласно опросу Python Software Foundation и JetBrains, Python чаще всего применяют в аналитике данных, веб-разработке и машинном обучении.

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

Другое преимущество языка кроется в большом комьюнити и множестве библиотек. NumPy, Pandas, Matplotlib и многие другие библиотеки стали стандартами для работы с данными.

За более чем 30 лет существования Python написаны популярные фреймворки для веб-разработки Django и Flask. Это в совокупности с его кроссплатформенностью, обширной экосистемой библиотек и простотой делает Python удобным инструментом для анализа данных, веб-разработки и машинного обучения.

Проблемы с производительностью и ограниченная пригодность для многопоточных систем

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

Python относится ко второй категории языков, в связи с чем уступает в производительности Go, Rust и Java.

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

Ещё одно «узкое» место Python — работа с многопоточностью. Чтобы избежать ошибки при работе с памятью сразу нескольких потоков есть механизм GIL. Он даёт доступ к одному участку памяти только одному потоку. С одной стороны, это помогает избежать ошибок, но с другой, затрудняет выполнение одинаковых параллельных задач.

Преимущества Go: удобный как Python, производительный как C++

Язык Go был создан в Google для решения сложных задач, требующих масштабирования и производительности, сохраняя при этом простоту разработки. В 2026 году Go преподнёс неожиданность: он упал с 7-го на 16-е место в рейтинге TIOBE (минус 1,49 п.п.) — это стало самым большим падением среди популярных языков. При этом Go остаётся самым высокооплачиваемым языком в России: медианная зарплата — 320 000 руб. по данным Хабр Карьеры за 2-е полугодие 2025 года.

Простота синтаксиса и высокопроизводительное выполнение

Go совмещает в себе производительность низкоуровневых языков как C++, простоту и удобство кода высокоуровневых, как Python.

Пример кода для вывода в консоли на Go:

Язык Go избегает сложных синтаксических конструкций и наследования, здесь нет перегрузки функций или операторов, неявных преобразований типов. Он прост и лаконичен.

Производительность Go на уровне С и C++. Достигается это благодаря следующим причинам:

• Он компилируемый со строгой типизацией данных;
• Современный сборщик мусора, который требует меньше ресурсов;
• Нет сложных конструкций по типу наследования;
• Адаптирован под работу с параллельными задачами.

Параллелизм в Go: почему он остаётся лучшим выбором для облачных инфраструктур в 2026 году

В Go хорошо реализован параллелизм — одновременное выполнение задач. Это достигается за счёт горутин и каналов.

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

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

Помимо параллелизма в языке Go есть конкурентность — быстрое переключение между разными задачами в рамках одного потока или процессора. Например:

• Мы выполняем задачу 1, но не до конца, замораживаем её.
• Выполняем до конца задачу 2.
• Выполняем, но не полностью задачу 3.
• Заканчиваем выполнение задачи 1 и возвращаемся к задаче 3.

В некоторых случаях такое «жонглирование» задачами повышает производительность.

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

Преимущества Rust: быстрый и безопасный

Rust выделяется среди других языков программирования своим уникальным подходом к управлению памятью и безопасности кода без ущерба для производительности. В рейтинге TIOBE на март 2026 года Rust находится за пределами топ-10, но он продолжает завоёвывать ниши, где критичны производительность и безопасность. Разберём по порядку.

Главная особенность Rust: безопасность памяти без сборщика мусора

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

В таких языках, как Java, Python, Go предусмотрены автоматические сборщики мусора. Это специальные программы, которые находят неиспользуемые забитые участки памяти и освобождают их.

В языках C и C++ таких сборщиков нет, и программист должен сам прописывать в коде когда и что вычищать из памяти.

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

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

Rust использует другой подход. У него нет сборщика мусора, но есть владение. Когда мы добавляем значение к переменной в Rust, то не просто записываем под неё участок памяти, но и указываем, что она этим участком «владеет».

Например:

В этом примере мы создали переменную s1 со значением «Привет, Rust!», она является владельцем этой строки.

Далее мы передали значение s1 в s2. Теперь s2 владеет строкой «Привет, Rust!», а не s1.

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

Мы можем создавать изменяемые и неизменяемые заимствования при помощи знаков «&» и «&mut», причём это работает не только с переменными, но и с массивами.

Пример заимствований:

Другая особенность Rust — область видимости. Область видимости — это блок кода, который выполняется в данный момент времени. Обычно это функции, циклы и выражения. Как только блок кода выполнен, он исчезает из области видимости, и Rust очищает память от типов данных, которые были в этом блоке кода. Так мы получаем возможность безопасно работать с памятью без использования сборщика мусора.

Высокая производительность на уровне C++ при минимальных рисках ошибок

Производительность Rust сопоставима с С, С++ и Go, но при этом он более безопасный и удобный с точки зрения отладки.

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

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

Rust в системном программировании и низкоуровневых приложениях

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

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

Другая особенность Rust заключается в работе с памятью. Мы уже разобрали как устроены владение, зависимости и область видимости. При желании в Rust можно управлять памятью вручную, как в C и C++. Это повышает вероятность ошибок, но придаёт гибкости коду.

Ещё он поддерживает кроссплатформенную разработку. Программу на Rust под Windows будет потом проще адаптировать под Android.

По этим же причинам Rust хорошо подходит для разработки низкоуровневых приложений. Его применяют в таких проектах, как VK, Twitter, Coursera, Dropbox и Mozilla Firefox.

Сравнение языков по ключевым критериям: производительность, зарплаты и область применения

Каждый из рассматриваемых языков имеет свои сильные стороны и области применения. Сравним Go, Rust, Java и Python по ключевым характеристикам, чтобы лучше понять, где и когда использование каждого из них наиболее оправдано.

Производительность: сравнение Go, Rust, Java и Python

Rust и Go более производительные, чем Python и Java, это следует из результатов тестов.

График сравнивает время выполнения задач для функций Lambda при различных объёмах выделенной памяти (в мегабайтах). Ось Y показывает продолжительность выполнения задач в секундах, а ось X — объём выделенной памяти для функции.

Python — самый медленный. Чем меньше мы предоставляем памяти, тем дольше он справляется с задачей, но при больших объёмах памяти он хоть и уступает Java, но близко к нему приближается.

Второй по медлительности язык — Java. Go и Rust находятся примерно на одном уровне производительности и сильно опережают Java и Python.

Зарплаты разработчиков в России: Go, Java, Python в 2025–2026 году

По данным Хабр Карьеры за второе полугодие 2025 года, медианные зарплаты разработчиков в России распределились так:

• Go — 320 000 руб. (самая высокая среди всех языков, +4% за полгода);
• Python — 229 000 руб. (+8%);
• Java — 226 000 руб. (+1%).

Парадокс: Go упал в рейтинге TIOBE, но остаётся самым дорогим языком на российском рынке. Это объясняется дефицитом специалистов: компании активно используют Go в продакшене, но найти опытного Go-разработчика по-прежнему сложно.

Простота изучения и развитие экосистемы

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

Python проще в изучении, чем Go, благодаря динамической типизации, однако уступает ему в производительности. Go, в свою очередь, имеет специфическую реализацию объектно-ориентированного программирования.

С точки зрения экосистемы, Java и Python — явные лидеры. Они присутствуют на рынке с 1990-х годов. За это время они обросли большим комьюнити, накопили обширную базу библиотек, фреймворков, готовых проектов и учебных материалов. У Go и Rust тоже всё это есть, но куда в меньших масштабах.

Применимость в разных областях: от облачных сервисов до высоконагруженных систем и микросервисов

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

Rust — производительный язык с очень строгой структурой и управлением памятью. На нём не так просто писать код как на Go и Python, но зато он получается более безопасным и оптимизированным. Поэтому Rust тоже хороший выбор для облачных сервисов, микросервисов и высоконагруженных систем.

Java уступает Go и Rust в производительности, но хорошо работает с многопоточностью и обладает большим количеством фреймворков и библиотек. Он стандарт индустрии.

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

На чём писать в 2026 году

Данные 2026 года показывают, что ситуация сложнее, чем казалось в 2024 году. Go неожиданно упал в рейтингах, Java продолжает терять позиции в TIOBE, но оба языка растут на GitHub и остаются востребованными работодателями.

Прогнозы развития: куда движутся Java и Python

Java и Python останутся востребованными языками в 2026 году. На российском рынке Java-разработчики получают медианные 226 000 руб., Python-разработчики — 229 000 руб. Оба языка стабильно представлены в вакансиях на hh.ru.

Java и Python обладают развитой экосистемой с большим комьюнити. На них написано уже очень много кода, и в 2026 году эти языки никуда не денутся. Глобально они будут развиваться медленнее, чем более новые языки, как Go и Rust, но из этого не следует, что они станут невостребованными.

Какие отрасли могут полностью перейти на Go или Rust

Нельзя сказать, что какая-то из отраслей возьмёт и полностью откажется от Java или Python в 2026 году, уж очень это ресурсозатратно. Падение Go в рейтинге TIOBE показывает, что даже быстрорастущие языки могут замедляться. Тем не менее Go и Rust продолжают укреплять позиции в области микросервисов, высокопроизводительных систем, DevOps и автоматизации.

Отдельно стоит выделить Rust и сферу системного программирования. Благодаря высокой производительности и безопасности он продолжает набирать обороты.

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

Ожидаемые изменения в экосистемах и возможные сценарии развития

Одно из возможных направлений развития Java — это ИИ и машинное обучение. Да, сейчас в этой области доминирует Python, но у него есть ограничения в производительности и проблемы с работой в многопоточном режиме. У Java тоже есть свои библиотеки для работы с ИИ, при этом он производительнее и хорошо справляется с многопоточностью.

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

Go будет увеличивать своё влияние в области облачных решений и микросервисов, несмотря на падение в рейтинге TIOBE. Рейтинг измеряет популярность в поисковиках, а не реальное использование. Kubernetes, Docker, Terraform, Prometheus — вся облачная инфраструктура написана на Go, и это не изменится.

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

Go и Rust однозначно стоит учить, эти языки продолжают расти в реальном применении. Но новичкам лучше сфокусироваться на Java и Python — с ними будет проще найти первую работу.

Проект представляет собой коллекцию скриншотов страниц, которые служат личными блогами и веб-ресурсами таких известных специалистов, как Джон Маккарти, Дональд Кнут, Роб Пайк и другие.

Рядом с изображениями сайтов есть ссылки на эти страницы.

Технические трудности и идеи для улучшения

Изначально проект начал набирать популярность благодаря посту на Reddit.

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

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

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

Идеи для оптимизации сайта

Кроме того, обсуждались способы улучшения сайта, чтобы сделать его более удобным.

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

Это могло бы значительно уменьшить потребление ресурсов и улучшить пользовательский опыт, особенно на мобильных устройствах.

Вдохновение для будущих разработок

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

Посмотреть на проект своими глазами можно по ссылке.

Первое, что бросается в глаза при работе с Go — его синтаксис. Он лаконичен и понятен, что делает разработку быстрой и приятной. Это одно из главных преимуществ Go — не нужно тратить кучу времени на изучение сложных конструкций и абстракций. Вот, например, как выглядит типичный сервер на Go:

Этот небольшой фрагмент кода запускает веб-сервер, который отвечает "Hello, Go!" на каждый запрос. Вы удивитесь, но именно такой минимализм делает Go невероятно удобным и мощным инструментом для создания backend'ов.

Параллелизм на Go: быстрые и лёгкие горутины

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

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

Безопасность: защищаем наш backend

Производительность — это важно, но безопасность не менее критична. Go предлагает множество инструментов для создания защищённых приложений. Например, чтобы избежать SQL-инъекций, используйте подготовленные запросы:

Это не только снижает риск инъекций, но и упрощает работу с базой данных. А для управления сессиями и безопасной авторизации на Go можно использовать токены JWT:

Использование токенов в приложении позволяет легко управлять аутентификацией и поддерживать безопасность на высоком уровне. Встроенные библиотеки вроде gorilla/csrf помогают защититься от CSRF-атак, а такие инструменты как go-playground/validator помогают валидировать данные.

Кэширование и масштабирование

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

Простой подход с использованием карты (словаря) для хранения данных кэша может сильно ускорить время ответа.

Инструменты мониторинга и тестирования

Производительность приложения — это не только быстрая обработка запросов, но и умение находить узкие места. Go поставляется с встроенными инструментами для профилирования и тестирования. Например, с помощью библиотеки net/http/pprof можно отслеживать, сколько памяти занимает ваше приложение, и где возникают задержки.

Пример интеграции с инструментом мониторинга Prometheus для сбора метрик:

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

Заключение

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

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

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

Таким образом, прямо сейчас более 2 млн npm-модулей доступны для использования без необходимости перехода на Node.js.

Новая система разрешений

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

Теперь ошибки прав доступа стали более понятными. Например, вместо старого Deno.errors.PermissionDenied, при проблемах с правами на доступ, Deno выдаст новый тип ошибки Deno.errors.NotCapable, что облегчает различение между ошибками ОС и самого инструмента.

Кроме того, Deno упростил работу с разрешениями для некоторых API. Например, доступ к основному модулю через Deno.mainModule больше не требует использования флага --allow-read.

Обновления также коснулись команд для запуска процессов: теперь использование флага --allow-run без списка разрешенных бинарных файлов сопровождается предупреждением, направленным на повышение безопасности кода.

Примеры использования и новые возможности

Помимо изменений в разрешениях, Deno теперь поддерживает высокоточное время без необходимости использования флага --allow-hrtime. Это упростит работу с такими задачами, как мониторинг производительности.

Deno 2.0 продолжает стабилизацию API, таких как WebGPU и FFI (интерфейс для взаимодействия с библиотеками на C). Эти функции больше не требуют использования флагов для работы, что значительно упрощает их использование.

Ознакомиться с полным списком улучшение и нововведений можно по ссылке.

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

Как это работает?

Busy Status Bar показывает на экране, например, сколько времени осталось до конца вашего созвона или когда вы снова будете доступны.

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

Кроме того, есть возможность автоматизации через открытое API — это находка для тех, кто любит настраивать всё под себя.

Точной информации об источнике питания устройства нет, но предполагается, что работает оно от аккумулятора.

Схожесть с другим проектом

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

Автор этого проекта также задумался о том, как быстро и ненавязчиво сообщить окружающим о своей занятости, и собрал прототип устройства с аналогичным функционалом. Судя по всему, именно из него и вырос Busy Status Bar.

Кому это пригодится?

Гаджет отлично подходит для тех, кто часто проводит созвоны или стримит. Например, он может автоматически показывать сообщение «On Call», когда включается микрофон на компьютере.

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

Где купить и сколько стоит?

Уже сейчас Busy Status Bar можно заказать на сайте Flipper Devices за $189. Также доступна бета-версия приложения для iOS и Android, чтобы управлять гаджетом прямо со смартфона.

В будущем планируется появления библиотек для популярных языков программирования: Python, Go, Node.js.