Go for Devs

🎁 1000 и один способ угробить продакшн из-за гонок данных в Go

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

Автор показывает не учебные примеры, а живые кейсы из продакшена:

• Неявный захват внешних переменных в замыканиях, где один пропущенный : превращает локальную переменную в общую
• http.Client, который в документации объявлен потокобезопасным, но внезапно ломается, если конкурентно менять его поля
• Мьютексы, которые формально используются корректно, но живут меньше, чем данные, которые должны защищать
• И стандартная библиотека, где map, bytes.Buffer и другие типы вовсе не рассчитаны на конкурентный доступ, хотя это не всегда очевидно из API

Race detector сильно помогает, но он не всесилен: часть гонок проходит мимо, а симптомы могут проявляться только под нагрузкой или в CI.

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

Если язык и экосистема делают гонки данных слишком лёгкими, рано или поздно за это заплатит продакшн.

@go_for_devs

❓ Почему Go, Rust и Zig такие разные: ценности, компромиссы и назначение языков

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

Go: минимализм и корпоративная предсказуемость
• Язык намеренно маленький, «умещается в голове», жертвует выразительностью ради стабильности
• Новые фичи проходят через очень высокий порог: отсюда долгие 12 лет без дженериков
• Простой slice, скрытый рантайм и GC избавляют от размышлений о памяти
• Заточен под командную разработку, читаемость и предсказуемую конкурентность

Rust: максимализм и гарантия безопасности
• Огромное число концепций, трейт-систем, слоёв абстракций; высокая когнитивная плотность
• Идея «абстракции без накладных расходов» реализована буквально: безопасность без рантайма, через статические гарантии
• Сложен в обучении, но даёт сильнейшие гарантии и библиотечную экосистему без «страха чужого кода»

Zig: свобода, ручной контроль и анти-OOP
• Самый молодой из тройки, ещё сырой, но философски наиболее радикальный
• Полностью ручное управление памятью, выбор аллокатора как часть архитектуры
• Нет скрытой магии: ни неявных выделений, ни рантайма, ни динамического полиморфизма
• Стимулирует data-oriented дизайн и большие предсказуемые аллокации вместо «графа объектов»
• Ощущается дерзким «анархистским» языком для тех, кому хочется полного контроля и минимум абстракций

📚 Читайте и комментируйте на Хабр.

@go_for_devs

В Go утечки ресурсов часто выглядят как мелочь: не закрыли тело HTTP-ответа, забыли defer rows.Close(), оставили открытый файл. Но под нагрузкой это может привести к падению сервиса. GC тут не спасает: он чистит память, а не системные дескрипторы.

GoLand 2025.3 получил анализ утечек, который ловит такие проблемы прямо во время написания кода.

В новой статье разбираются реальные кейсы, где один пропущенный Close() приводил к росту памяти, ошибкам can’t assign requested address и полному исчерпанию SQL-коннекшенов из-за единственного NULL в таблице.

Инструмент отслеживает все пути выполнения, включая пользовательские типы с io.Closer, и подсвечивает, где ресурс может остаться открытым.

📚 Читайте и комментируйте на Хабр.

@go_for_devs

⚡️ Вышел GoLand 2025.3

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

Коротко — самое важное:

— Новый анализатор утечек ресурсов (файлы, коннекты, дескрипторы).
— Поддержка нескольких ИИ-агентов: теперь Junie + встроенный Claude Agent.
— Terraform встроен по умолчанию, работает прямо из коробки.
— Крупные улучшения Kubernetes-инструментов: CI/CD-флоу прямо в редакторе.
— Новая тема интерфейса Islands по умолчанию.
— Возможность открывать отдельные файлы без проекта.
— Полная поддержка golangci-lint fmt из версии 2.
— Существенный прирост производительности: меньше OOM-предупреждений, умнее индексирование, отзывчивее UI.

📚 Читайте и комментируйте на Хабр.

@go_for_devs

🚀 Лучше, чем JSON: почему я перешёл на Protobuf

Опубликовали перевод статьи автора, который уже почти десятилетие не использует JSON в своих API и сознательно выбирает Protobuf.

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

Protobuf же работает совсем иначе:
• контракт описывается в .proto — чёткие типы, стабильные теги
• сгенерированный код избавляет от ручного парсинга и ошибок
• бинарный формат получается в разы компактнее JSON
• экономия на сети, CPU и мобильном трафике чувствуется сразу

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

📚 Читайте и комментируйте на Хабр.

@go_for_devs

⚡️ JetBrains представила Air: новую агентную IDE

Компания выпустила Air — ADE (Agentic Development Environment), ориентированную на гибридную работу «разработчик + ИИ-агенты».

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

Air пока доступен в превью и работает только с одним агентом — Claude Agent, причём для использования требуется активная подписка Anthropic.

Версии для Windows и Linux обещают в 2026 году — сейчас приложение доступно только на macOS.

Сайт | Документация | Анонс в X | Анонс на Habr

@ai_for_devs

😱 MinIO: развитие остановлено

Команда MinIO объявила, что проект уходит в чистый maintenance-mode. Никаких новых фичи, PR’ов и даже review существующих изменений.

Останутся только точечные фиксы критических уязвимостей (и то по ситуации).

Активное развитие теперь живёт в их enterprise-решении MinIO AIStor.

Такой вот Open Source :)

@go_for_devs

🔍 Как Go-компилятор превращает ваш код в токены

Опубликовали отличный разбор того, с чего реально начинается компиляция Go — со сканера (или лексера). Того самого компонента, который посимвольно читает ваш код и превращает его в поток токенов.

Сканер в Go работает удивительно прямолинейно: видит букву — пытается идентификатор, сверяет с таблицей ключевых слов; видит + — решает, это +, ++ или +=; встречает перевод строки — вставояет точку с запятой.

Что занятно — у Go два сканера. Один из стандартной библиотеки (go/scanner), другой — тот, что реально кормит компилятор (src/cmd/compile/internal/syntax/scanner.go). И именно второй делает всю тяжёлую работу: буферизует вход, трекает позиции, прокручивает Unicode, следит за состоянием вставки ; и т.д.

В статье пошаговый разбор классического hello world. Хорошее чтиво.

@go_for_devs

😎 Про новый GC в Go теперь уже в формате доклада

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

А теперь к этому добавился и свежий доклад c GopherCon 2025: "Advancing Go Garbage Collection with Green Tea".

Теперь можно не только прочитать, но и посмотреть!

@go_for_devs

💧 Симуляция воды на Go

Подготовили для вас перевод статьи Тима Литтла, где он на чистом Go и raylib-go собирает лёгкую симуляцию воды для 2D-игр. Без сложной физики и уравнений Навье—Стокса.

Под капотом — сетка из `Droplet`-ячееек, у каждой свой объём воды.

Дальше автор по шагам накручивает поведение:

🟣 Гравитация: капли падают вниз, пока есть свободное место;
🟣 Боковой поток: если низ забит — вода растекается влево и вправо;
🟣 «Давление»: остатки утекают по диагонали, заполняя пустоты;
🟣 Препятствия: вода огибает блоки, переливается через «платформы» и красиво стекает вниз.

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

Конечно, вряд ли пригодится завтра на работе, но выглядит прикольно)

@go_for_devs

🛡️ Современная защита от CSRF/CORF в Go без токенов

Перевели практичную статью Алекса Эдвардса о том, можно ли жить без CSRF-токенов. Спойлер: да, но только если вы готовы соблюдать набор довольно жёстких условий. Зато результат — чистый код, меньше зависимостей и защита, встроенная в сам браузер + Go 1.25.

Главная звезда статьи — новый middleware http.CrossOriginProtection. Он использует современные браузерные заголовки (Sec-Fetch-Site и Origin) и просто отсекает все «подозрительные» небезопасные запросы, которые не пришли с того же origin. Без танцев с токенами, без внешних библиотек — прямо в стандартной библиотеке Go.

Автор подробно разбирает, как это работает под капотом: браузеры автоматически добавляют Sec-Fetch-Site, Go сравнивает origin-ы, а если заголовков нет — предполагает, что запрос пришёл не из браузера. Плюс — пропускаются только безопасные методы.

Но, как всегда, есть нюансы. Защита работает только с современными браузерами. Если юзер сидит на чём-то старше 2020 года — токены могут понадобиться. И тут появляется главный лайфхак статьи: если вы требуете TLS 1.3, то все браузеры, которые вообще смогут подключиться, уже гарантированно поддерживают нужные заголовки. Исключение — старые Firefox 60–69, но их доля настолько мала, что это скорее исторический артефакт.

Отдельная часть статьи — аккуратное объяснение разницы между cross-origin и cross-site. Это важно, потому что Go блокирует именно cross-origin, и это круто: атаки с ваших соседних поддоменов тоже не пройдут. Плюс — небольшой разбор SameSite-cookie: в сочетании с TLS 1.3 они закрывают последние дыры, которые могут остаться после Firefox-исключения.

📚 Полный разбор: https://habr.com/ru/articles/968132/

🔥 Самая важная новость недели)

Git 3.0 по умолчанию будет создавать ветку main!

Через 16 лет после появления master Git меняет дефолтную ветку на main, чтобы точно не задеть ни чьи чувства 😊

История вопроса тянется давно. Software Freedom Conservancy ещё в 2020 году заявила о планах отказаться от master в пользу более нейтрального названия.

Через несколько месяцев этот шаг сделал GitHub, автоматически создавая main во всех новых репозиториях. Но сам Git до сегодняшнего дня сохранял старое поведение, перекладывая ответственность на пользователя.

Git 2.52 уже закрепил это в патч-нотах, а к релизу 3.0 (где-то в 2026) проект ждут и другие апгрейды: переход на SHA-256, новый формат хранения и даже чуть-чуть Rust под капотом.

Ушла эпоха)

@go_for_devs

💡 Почему маленькие интерфейсы делают Go-код ощутимо лучше

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

Автор показывает всё на конкретном коде: сначала простой FileStorage, который вроде бы удобен… пока не нужно протестировать функцию, использующую всего один метод. Потом — S3-клиент из AWS SDK, где желание «обернуть всё интерфейсом» быстро приводит к монстру из десятков методов, который привязывает весь проект к одному определению.

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

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

📚 Читать на Хабр: https://habr.com/ru/articles/967730/

📊 Экосистема Go сегодня: что изменилось в 2025 году

Перевели подробный разбор того, как эволюционировала экосистема Go к 2025 году — от фреймворков и тестовых библиотек до инструментов для DevOps и AI-редакторов.

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

Мы всё так же используем gin, net/http и GoLand. Разве что значительно выросла доля тех, кто предпочитает встроенный пакет testing — теперь им пользуются 60% разработчиков против 35% пять лет назад.

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

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

@go_for_devs

🫡 Gemini 3 Pro стала доступна в JetBrains IDE

Думаю все уже слышали, что вчера вышла Gemini 3 Pro Preview – флагманская модель от Google, SOTA практически по всем известным бенчмаркам.

Исключением как раз является SWE-бенч. В нём Claude Sonnet 4.5 остался лидером.

JetBrains добавили Gemini 3 Pro в свои IDE. Теперь она доступна в AI Chat, а скоро доберётся до Junie, фирменного агента от JetBrains.

@go_for_devs

🐘 Kafka реально быстрая, но я возьму Postgres

Перевели довольно длинный, но приземлённый разбор: зачем большинству проектов вообще тащить Kafka и пять разных баз, если тот же Postgres спокойно закрывает типичные нагрузки. Автор не просто рассуждает — он гоняет бенчмарки и смотрит, насколько далеко можно уехать на одном Postgres в сценариях pub/sub и очередей.

Если коротко, то по мир можно поделить на два лагеря:

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

🟣 Второй — те, кто начинают с базовых вещей и считают не только RPS, но и организационные издержки: новые системы надо изучать, мониторить, обновлять, поддерживать, и это обходится дороже, чем кажется. На этом фоне логика «просто используйте Postgres, пока не упрётесь в реальные лимиты» выглядит вполне рационально.

В бенчмарках Postgres выступает как и pub/sub, и очередь: десятки тысяч сообщений в секунду, мегабайты входящего/исходящего трафика, на относительно скромных инстансах и без экзотического тюнинга. Да, Kafka и спецочереди по-прежнему лучше оптимизированы под свои задачи и выигрывают на очень больших масштабах. Но до этих масштабов большинство систем просто не доходит — и в подавляющем числе кейсов упираться будете не в базу, а в продукт, команду или деньги.

Вместо «архитектуры как у Google» лучше думать в терминах минимально жизнеспособной инфраструктуры: взять Postgres и использовать его максимально просто и добавлять новые технологии только тогда, когда они реально нужны. Чем меньше компонентов — тем меньше точек отказа и меньше клейкого кода между ними.

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

@go_for_devs

😬 TOON: новый формат на смену JSON для более эффективного взаимодействия с LLM?

TOON — это ещё один способ записать те же самые JSON-данные, но компактнее и понятнее для моделей. Вместо  "key": "value" он использует отступы как YAML и табличную запись для массивов объектов: шапка с названиями полей, дальше строки с данными.

Пример из README: вместо обычного JSON с пользователями — строка users[2]{id,name,role}: и две строки 1,Alice,admin и 2,Bob,user. Структура при этом не теряется: объекты, массивы и примитивы остаются теми же, формат — просто «другая запись» того же JSON.

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

В бенчмарках TOON даёт порядка 30–60% экономии токенов на больших ровных массивах объектов по сравнению с форматированным JSON и заметно меньше, но всё равно ощутимо — против compact JSON. На ряде задач TOON показывает чуть более высокую точность ответов, чем обычный JSON при меньшем числе токенов.

При этом авторы честно фиксируют зоны, где TOON не выгоден.

Если структура сильно вложенная, неравномерная и почти не подходит под табличный вид, компактный JSON в тестах иногда оказывается короче. Если данные вообще чисто табличные и плоские, CSV по-прежнему даёт минимальный размер, а TOON добавляет небольшой оверхед ради явной структуры и валидации.

То есть формат заточен именно под «много однотипных объектов с примитивными полями», а не под любые данные подряд.

Для использования уже есть CLI через npx @toon-format/cli и TypeScript-библиотека @toon-format/toon.

@ai_for_devs