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

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

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

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

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

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

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

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

@go_for_devs

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

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

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

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

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

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

🛡️ Современная защита от 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/

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

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

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

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

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

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

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

@go_for_devs

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

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

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

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

@go_for_devs

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

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

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

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

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

@go_for_devs

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

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

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

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

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

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

@go_for_devs

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

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

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

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

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

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

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

@go_for_devs