Go *

Вы попросили ChatGPT добавить скидку 10% на заказы больше $100. Он выдал 40 строк кода. Скидка работает - проверили на заказе в $150, получили $135. Закоммитили.

Чего вы не заметили: модель переписала функцию расчёта цены целиком. Не потому что нужно было. Просто так получилось - LLM не "редактирует" код, он генерирует новый текст на основе вашего промпта и контекста. В процессе он изменил порядок вычисления налога. Заказы меньше $100 теперь считают налог дважды. Товар за $10 стоит $10.80 вместо $10.50. Вы узнаете об этом через три недели, когда клиент напишет в поддержку.

Когда в феврале 2022-го вышел Go 1.18 с дженериками, сообщество разделилось на два лагеря. Первые кричали «наконец-то!» и бросились переписывать всё подряд. Вторые — «не нужны были, не нужны и сейчас». Прошло три года. Пыль улеглась. И я хочу поговорить не о том, как написать func Max[T constraints.Ordered](a, b T) T — этому посвящены тысячи туториалов. Я хочу поговорить о том, что реально прижилось, какие паттерны оказались полезными, а где дженерики только мешают.

До 1.18 у нас было два пути: дублировать код под каждый тип или использовать interface{} (а теперь any) с приведением типов в рантайме. Оба такой вот компромисс.

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

На дворе конец 2023. Я только что уволился из Яндекса и скучаю по ячану, чуть меньше скучаю по этушке, вообще не скучаю по таскам, дедлайнам, ревью. Чтобы заполнить возникший информационный вакуум, пробую переключиться на реддит, hacker news, пикабу, вышивание крестиком, сканворды, пилатес — не то. Тогда мне в голову приходит гениальная идея: а почему бы не сделать свою имиджборду с авторизацией по корпоративной почте крупных российских компаний? Ячан для всех!

Первая мысль — взять готовый движок и допилить под себя, в открытом доступе уже есть: lynx, vichan, wakaba, kareha, fchannel. Потыкался — ничего не понятно. Как ленивый человек решаю, что надо писать своё.
На тот момент я:

Не понимал разницу между HTTP и HTTPS

Не знал, что такое handler, router, middleware

Считал, что DNS — это какой-то раздел электронной музыки

Думал, что куки и кэш — это одно и то же

Не без труда отличал header от body

Не мог пропатчить kde2 под freebsd

Короче говоря, я был именно тем человеком, который должен был писать проект с нуля. Цель понятна, надо выбрать инструменты. Я неплохо знал питон и c++... поэтому языком разработки выбрал Голанг. Мой опыт с Голангом на тот момент ограничивался прослушанным фоном на х2 ШАДовским курсом. Прослушал я его в автопоездке Москва — Челябинск. Не написал на Го ни одной строчки кода, но суммарно прослушал — именно «прослушал», ибо рассмотреть мелкий шрифт на экране телефона, будучи за рулём, решительно невозможно — около 30 часов материала. Написать свой движок имиджборды - хороший повод попрактиковаться.

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

Привет! На связи вновь команда Геосервисов. Как вы помните, в прошлой статье я делился нашим опытом партиционирования и теми выводами, к которым мы пришли. Но на этом история не закончилась. Что же было дальше?

Партиционирование завершилось успешно. VACUUM сократился с 6+ часов до ~20 минут. Запросы ускорились. Мы думали, что всё позади. Через неделю после swap проверили реплику — и обнаружили, что она пуста.

Если посчитать публичный API Ginkgo, получается внушительный список. Describe, Context, When, It, Specify, By, BeforeEach, AfterEach, BeforeAll, AfterAll, JustBeforeEach, JustAfterEach, BeforeSuite, AfterSuite, SynchronizedBeforeSuite, SynchronizedAfterSuite, DeferCleanup. Семнадцать функций, и это без F- и P-вариантов для focus и pending.

GoConvey проще, но и у него набирается не меньше: Convey, So, ShouldEqual, SkipConvey, FocusConvey, Reset и собственный DSL для assertion-ов.

Какой минимальный API нужен scoped-фреймворку для тестирования?

Привет, Хабр! Меня зовут Олег, я работаю в VK Cloud в команде Key Management Service. Есть у меня такая привычка: когда пользуюсь каким-то инструментом изо дня в день, то рано или поздно хочется залезть внутрь и посмотреть, как оно там устроено. С контейнерами так и вышло: docker run, docker build — всё это прекрасно работает, но что именно происходит, когда мы «запускаем контейнер»?

В этой статье разберём контейнеры не на уровне «вот вам YAML, отправляйте в прод», а чуть глубже — на уровне системных вызовов Linux. По ходу дела напишем свой примитивный контейнер на Go, используя буквально четыре syscall'а, а в конце посмотрим, куда эта история развивалась дальше (сети, файловые системы) и почему виртуальные машины всё ещё живы.

Всем привет! Поводом для написания этой статьи послужила ситуация, с которой мы в команде Геосервисов столкнулись.

Когда наша база данных нормализованных OSM-данных достигла размеров в 600+ ГБ, VACUUM стал занимать 6+ часов. Мы начали приближаться к пределу хранилища (600 GB из 1 TB), а производительность запросов деградировала. Стало очевидным — партиционирование неизбежно.

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

Состоялся релиз OpenIDE 2025.3 на базе IntelliJ IDEA Platform 2025.3. В релизе — поддержка Java 25, автодополнение действий IDE через двойную точку (Command Completion), Spring MCP для LLM-агентов, обновления для Go и фронтенд-стека, улучшения HTTP-клиента Connekt и доработки Docker-плагина. 

Привет, Хабр. Я Матвей Лихота, старший Go-разработчик из МТС Web Services. По моему опыту, документация, которую пишут руками отдельно от кода, устаревает уже в момент следующего коммита. Из-за этого мы в команде тратили до 20% времени на поддержание актуальности swagger-документации в десятке микросервисов. И когда ошибки интеграции уже стали привычным фоном, мы все-таки решились и перевернули всё с ног на голову: внедрили Documentation-Driven Development (DDD) — подход в разработке, когда процесс начинается с документации. 

Что за подход и что он дал в итоге, зачем понадобилась утилита oapi-codegen и как мы генерируем Go-код из OpenAPI-спецификаций — подробно рассказал и показал под капотом. 

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

Если вы работаете с GitLab и у вас больше одного окружения — вы наверняка знаете этот ритуал: открываешь Settings → CI/CD → Variables, начинаешь вбивать переменные вручную, на пятой ошибаешься, на двадцатой теряешь счёт, на пятидесятой начинаешь сочувствовать тем, кто хранит секреты прямо в коде.

Я написал glenv — CLI-инструмент на Go, который синхронизирует .env файлы с GitLab CI/CD переменными через API. Под катом — история о том, почему существующих решений не хватило, как это устроено внутри и несколько примеров использования.

Осенью 2025-го у нас ушёл мидл. Типичная история — нашёл +80к в каком-то финтехе, ему там обещали «плоскую структуру и свободу принятия решений» (спойлер: через три месяца он написал мне что хочет вернуться, но мы уже наняли замену). Замену, кстати, нашли не быстро. Провели штук двадцать собесов, может больше, я со счёта сбился после пятнадцатого.

Рынок такой: половина не может обход дерева написать (я серьёзно, я уже думал может я что-то не так спрашиваю, но нет), трое врали про опыт настолько плохо что мне неловко было за них, и один спросил можно ли работать из Бали при условии что созвоны в девять утра. Нельзя, у нас on-call.

Короче, появился кандидат. Назову его Дима.

Пример паттерна Worker Pool на Go с подробным описанием кода. Пример подходит для знакомства с паттерном в процессе обучения, собеседования, но не является шаблоном для production кода.

B4 - инструмент обхода DPI на Go с веб-интерфейсом.

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

Технология eBPF у всех на слуху, но написать свой инструмент и получить все выгоды от eBPF не так просто из-за недостатка информации. 

Привет, Хабр! Я — Дмитрий Самохвалов, архитектор в компании К2Тех. Помимо этого пишу на GO и на Rust, и стараюсь делать жизнь наших инженеров и разработчиков интереснее и проще. В этой статье по мотивам доклада с Golang Conf я расскажу, как мы пришли к работе с eBPF и покажу на примере написания своего XDP-фильтра, как начать работу с eBPF, используя Go. 

TLDR: Создана рабочая легковесная реализация AmneziaWG для Mikrotik для подключения к AmneziaWG серверам.

Оффлайн(!) конфигуратор на основе AWG-конфига, копия gitlab

Исходники в Github (MIT) копия на gitlab (плз форкайте, а то уже разок github снес мой проект)

upd: Добавлена поддержка протокола AmneziaWG v2.

Notte — платформа для автоматизации браузера. Недавно мы выпустили CLI, который позволяет управлять браузерными сессиями, запускать AI-агентов, извлекать структурированные данные и развёртывать функции автоматизации — всё это прямо из терминала.

В этой статье разберём, что он умеет и как устроен.

Какую проблему мы решали

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

Notte CLI подключается напрямую к облачным браузерным сессиям. Браузер запущен не у вас — он работает у нас. Это означает, что то, что вы делаете в терминале, в точности совпадает с тем, что будет работать в продакшне.

Как работают сессии

Весь CLI построен вокруг сессий. Сессия — это живой экземпляр браузера (headless или headed), запущенный в облаке.

Запустить её можно так:

notte sessions start --headless

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

При запуске сессии поддерживается широкий набор настроек: кастомные viewport'ы, user agent'ы, ротация прокси, решение капч, файловое хранилище, переопределение CDP URL и сохранение профиля браузера.

Видимость

При запуске headless-сессии в выводе появляется viewer URL. Откройте его в браузере — и вы наблюдаете за живой сессией в реальном времени, пока команды выполняются в терминале. Удобно для отладки без переключения в отдельный интерфейс.

Выйдя на пенсию и имея много свободного времени, я решил посвятить себя любимому занятию - разработке высоконагруженных финансовых архитектур, ядер и протоколов межбанковского клиринга (проект Orda). Я создал Qazna - проект, который называю «финансовым Linux», полностью переведенный на строгую открытую лицензию GNU AGPLv3.

Ежедневно ковыряясь в архитектуре систем, отлавливая уязвимости на пайплайнах (вроде недавних багов в crypto/tls в стандартной библиотеке Go) и выстраивая отказоустойчивые сети, я поймал себя на одной мысли. Мы тратим колоссальные ресурсы на защиту серверов и протоколов, но игнорируем самую уязвимую систему с устаревшим legacy-кодом - нас самих.

Этот пост - попытка выйти за рамки классического IT и посмотреть на историю, политику, общество и медицину через призму системного анализа, API-инъекций и социальной инженерии. Документ "Тартар и Я", над которым я работал до этого, натолкнул меня на мысль, что праязык человечества - это не утерянный миф, а живой код. И сегодня я хочу поговорить о том, как этот код компилируется в нашу реальность.

Когда мы говорим о программировании, мы по привычке представляем кремниевые процессоры, серверные стойки и строки кода на Python, Go или C++. Но мы упускаем из виду одну фундаментальную вещь: задолго до появления первых ЭВМ человечество уже создало мощнейший язык программирования - нашу речь.

Язык - это не просто средство коммуникации. Это низкоуровневый фреймворк, на котором «крутится» наше сознание. Как я отмечал в материалах к исследованию "Тартар и Я", слова несут в себе архетипические смыслы, формирующие саму логику мышления. И если мы признаем, что человек программируется языком, возникает закономерный вопрос: насколько хорошо защищена наша внутренняя операционная система?

Когда мы говорим о сборщике мусора, мы часто ограничиваемся фразой «он удаляет неиспользуемые объекты», однако в реальности GC — это сложнейшая система, которая взаимодействует с виртуальной памятью, потоками, стеком, регистрами и графом ссылок, и без понимания этих взаимодействий невозможно осознанно писать высоконагруженные приложения. В этом материале мы сосредоточимся именно на GC, рассматривая его не как магию runtime, а как конкретный набор алгоритмов и инженерных компромиссов. За каждой строкой new, за каждой локальной переменной и за каждым вызовом функции стоит конкретная архитектура процессора, виртуальная память операционной системы и довольно агрессивная инженерная математика сборщика мусора. Чтобы действительно понимать GC, необходимо начать не с него, а с того, на чём он стоит — с регистров, стека и кучи, поскольку именно они формируют корневую модель, на которую опирается любой современный runtime.

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

Совсем недавно сложно было представить что простым людям так быстро станут доступны инструменты ИИ агентов. Но технологии не стоят на месте. И вот в конце января 2026 года набирает популярность бесплатный и автономный агент, разработанный Питером Штайнбергером - OpenClaw (ранее Clawdbot и Moltbot). Инструмент очень быстро набирает популярность и буквально за считанные дни репозиторий в github становится самым быстрорастущим за всю историю площадки, обогнав Kubernetes. Такая популярность не могла не привлечь и широкое внимание конкурентов. Так появляется PicoClaw легковесный агент от китайских разработчиков, написанный на языке Go. Вот список некоторых особенностей PicoClaw:

Сверхлёгкое потребление ресурсов: работает на менее чем 10 МБ ОЗУ, что примерно на 99 % меньше, чем у OpenClaw (>1 ГБ) и значительно меньше NanoBot (>100 МБ). Это позволяет запускать ИИ-ассистента на очень дешёвом оборудовании.

Минимальные аппаратные требования: запускается даже на устройствах стоимостью около $10 (например, RISC-V платы вроде LicheeRV Nano), в то время как многие альтернативы требуют мощности серверного класса или ПК.

Молниеносный запуск: стартует за <1 секунду, даже на медленных процессорах с частотой ~0.6 ГГц, обеспечивая гораздо более быстрый отклик, чем у конкурентов, где загрузка может занимать десятки или сотни секунд.

Высокая переносимость: представляет собой один бинарный файл на Go, без тяжёлых зависимостей, и поддерживает разные архитектуры — RISC-V, ARM64 и x86, что упрощает использование на разнообразных устройствах.