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

🚀 1 млн запросов в секунду на Go: уроки продакшена

Если у вас read-heavy API, бить по базе или Redis на миллион RPS — заведомо проигрышная стратегия.

Ключевая идея — распределённый In-Memory Cache, синхронизируемый через события:

🟠 Write-сервис пишет в БД и публикует обновления
🔵 Read-сервисы подписываются на события и обновляют локальный кэш
🟡 Чтение обслуживается напрямую из памяти, без I/O

В результате один pod выдерживает ~60k RPS, а миллион запросов закрывается менее чем 20 pod’ами.

📚 Практика, цифры и код — в новой статье на Хабре.

@go_for_devs

🤜 Наткнулись на сравнение Go и TypeScript

— В статике Go и Bun почти равны, Bun доходил до ~200k RPS
— С БД Go стабильнее: ниже latency, аккуратный пул, ~84k RPS
— Bun сильнее нагружает Postgres из-за агрессивных коннектов

Отдельно занятный момент: в комментарии пришёл автор фреймворка для Bun. Он отметил, что тест можно ещё улучшить: автоматический роутинг через Bun.serve.routes даёт до ~15% прироста, продакшен-сборка через bun build --compile заметно снижает память (до ~40%), а new Date(Date.now()) вообще избыточен и слегка бьёт по перфу.

То есть Bun можно выжать ещё сильнее — но в stateful-кейcах Go всё ещё выглядит надёжнее.

@go_for_devs