1207
По сотрудничеству пишите в личные сообщения канала.
⚡️ Anthropic выпустили Claude Opus 4.7
Cursor зафиксировал рост с 58% до 70% на своём бенчмарке, Rakuten — трёхкратный рост решённых production-задач.
Новый уровень effort xhigh добавили между high и max. В Claude Code он теперь включён по умолчанию.
Параллельно вышел /ultrareview в Claude Code — команда запускает отдельную review-сессию, которая прогоняется по всем изменениям и ищет баги и архитектурные проблемы.
Цена та же: $5/$25 за млн токенов.
@ai_for_devs
Помните, осенью мы писали про запуск опроса Go Survey 2025. Так вот, вчера команда Go опубликовала результаты!
В опросе приняли участие 5 379 разработчиков.
Коротко по результатам:
🟣 Профиль выборки: 87% — профессиональные разработчики, 82% используют Go в основной работе, 72% — ещё и в личных/OSS-проектах. Возраст 25–45 указали 68%, стаж в разработке 6+ лет — 75%. При этом 81% сообщили, что их общий опыт разработки больше, чем опыт именно с Go — Go чаще становится “вторым языком”. Доля новичков с опытом Go < 1 года снизилась до 13% (в 2024 было 21%).
🟣 Отношение к языку стабильно положительное: 91% сказали, что им комфортно работать с Go, и почти ⅔ выбрали вариант “очень доволен(на)”. На этом фоне заметнее звучат конкретные “точки трения”: 33% сложнее всего “держать код идиоматичным/по best practices”, 28% говорят, что в Go нет важных для них возможностей из других языков, 26% отмечают сложность поиска надёжных модулей и пакетов.
🟣 Отдельный сигнал — базовые команды go: 15–25% респондентов (кроме go test) часто возвращаются к документации по подкомандам вроде go build, go run, go mod, и жалуются именно на навигацию и читаемость help-системы.
🟣 Инструменты и окружение: разработка в основном на macOS (60%) и Linux (58%), развёртывание почти полностью на Linux-окружениях/контейнерах (96%). Среди редакторов лидируют VS Code (37%) и GoLand (28%); новые Zed и Cursor выбрали по 4%.
🟣 ИИ-инструменты уже стали рутиной, но без “вау-метрики”: 53% используют их ежедневно, 29% — почти не используют. “Агентный” режим — ранняя стадия: основной формат у 17%, “иногда пробую” — 40%. Удовлетворённость средняя: 55% в целом довольны (из них 42% — “скорее”, 13% — “очень”). Главные проблемы качества: 53% сталкиваются с генерацией неработающего кода, 30% — с рабочим, но низкого качества. При этом большинство не добавляет ИИ-фичи в Go-продукты (78%), и у 66% софт вообще не использует ИИ.
🔥 Перевели хороший разбор про атомарные операции и мьютексы в Go — на примерах и с бенчмарками, без абстрактной теории.
Коротко: sync/atomic действительно быстрее. В простом кейсе с одним общим счётчиком атомики дают ~3× выигрыш по времени операции по сравнению с sync.RWMutex. Это ожидаемо: одна инструкция CPU против захвата блокировки, пусть даже с быстрым путём в рантайме Go.
Проблемы начинаются, как только логика перестаёт быть «одна операция — одно поле». Атомарные операции защищают ровно одну инструкцию. Последовательность прочитать → проверить → записать уже не атомарна. Для корректности приходится переходить к CAS-циклам, ретраям, лимитам попыток. Код быстро обрастает условиями, и цена ошибки становится выше, чем выигрыш в наносекундах.
Из статьи я бы вынес одно практическое правило. Начинать стоит с мьютекса.
Атомарные операции — это инструмент точечной оптимизации, когда:
* объект — одно значение или независимые счётчики,
* нет сложных инвариантов,
* выигрыш подтверждён измерениями, а не ощущениями.
Во всех остальных случаях простота и локальная очевидность кода обычно оказываются важнее разницы между 30 и 100 наносекундами.
📚 Читать на Хабр: https://habr.com/ru/articles/986732/
⚡️ В Go 1.26 (релиз которого планируется в феврале) добавят поддержку SIMD
SIMD (Single Instruction, Multiple Data) — это способ выполнять одну инструкцию сразу над набором данных. Проще говоря, процессор может сложить, умножить или сравнить сразу несколько чисел за один такт. Это критично для задач вроде обработки массивов, графики, ML, криптографии и любых data-heavy пайплайнов — прирост производительности там может быть кратным.
В следующей версии Go появится новый низкоуровневый пакет simd/archsimd, и на старте — только amd64. Команда Go сознательно начала с архитектурно-специфичного API, отложив высокоуровневые абстракции, чтобы сначала получить реальный фидбэк от разработчиков.
Подход разумный. SIMD сильно зависит от железа, и преждевременный «универсальный» интерфейс легко может стать ошибкой.
SIMD в индустрии появился давно, но почти везде путь был болезненным:
– C / C++ живут с SIMD десятилетиями, но ценой сложного и хрупкого кода: разные заголовки, ручной выбор инструкций, слабая переносимость.
– Rust долго шёл к стабильному SIMD: первые версии API ломались, часть решений признали неудачными, прежде чем остановиться на архитектурно-разделённом подходе.
– Java больше десяти лет избегала SIMD вовсе и только недавно представила Vector API — после серии прототипов и экспериментов с производительностью и переносимостью.
⚡️ Две короткие новости про Claude Code
Во-первых, Anthropic добавили нативную поддержку LSP — включая Go. Агент теперь работает не через grep и эвристики, а видит семантику кода как IDE: go-to-definition, ссылки, типы, символы. Для больших кодовых баз и рефакторинга — качественный скачок.
Во-вторых, на новогодние праздники удвоили лимиты для подписок Pro и Max — с сегодняшней ночи и до конца года.
Если до сих пор не пробовали AI-помощников разработчика в деле, то стоит начать. В 2026 это точно станет БАЗОЙ.
@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
🎁 1000 и один способ угробить продакшн из-за гонок данных в Go
Наткнулись и перевели большую и очень интересную статью про гонки данных в Go от человека, который годами находит и чинит их в реальных системах.
Автор показывает не учебные примеры, а живые кейсы из продакшена:
• Неявный захват внешних переменных в замыканиях, где один пропущенный : превращает локальную переменную в общую
• http.Client, который в документации объявлен потокобезопасным, но внезапно ломается, если конкурентно менять его поля
• Мьютексы, которые формально используются корректно, но живут меньше, чем данные, которые должны защищать
• И стандартная библиотека, где map, bytes.Buffer и другие типы вовсе не рассчитаны на конкурентный доступ, хотя это не всегда очевидно из API
Race detector сильно помогает, но он не всесилен: часть гонок проходит мимо, а симптомы могут проявляться только под нагрузкой или в CI.
Интересна и более общая мысль статьи: если такие ошибки регулярно допускают опытные инженеры, значит проблема не только в внимательности. Неявные замыкания, мелкое копирование структур с ссылочными полями, отсутствие встроенного Clone(), слабая документация по потокобезопасности — всё это увеличивает вероятность гонок, даже в аккуратно написанном коде.
Если язык и экосистема делают гонки данных слишком лёгкими, рано или поздно за это заплатит продакшн.
В Go утечки ресурсов часто выглядят как мелочь: не закрыли тело HTTP-ответа, забыли defer rows.Close(), оставили открытый файл. Но под нагрузкой это может привести к падению сервиса. GC тут не спасает: он чистит память, а не системные дескрипторы.
GoLand 2025.3 получил анализ утечек, который ловит такие проблемы прямо во время написания кода.
В новой статье разбираются реальные кейсы, где один пропущенный Close() приводил к росту памяти, ошибкам can’t assign requested address и полному исчерпанию SQL-коннекшенов из-за единственного NULL в таблице.
Инструмент отслеживает все пути выполнения, включая пользовательские типы с io.Closer, и подсвечивает, где ресурс может остаться открытым.
📚 Читайте и комментируйте на Хабр.
@go_for_devs
🚀 Лучше, чем JSON: почему я перешёл на Protobuf
Опубликовали перевод статьи автора, который уже почти десятилетие не использует JSON в своих API и сознательно выбирает Protobuf.
JSON стал стандартом веба во многом случайно: человекочитаем, встроен в JavaScript, тривиален в инструментах и позволял «просто работать». Но при активной разработке он же создаёт хаос: отсутствующие поля, неверные типы, нет гарантий структуры, валидация вручную.
Protobuf же работает совсем иначе:
• контракт описывается в .proto — чёткие типы, стабильные теги
• сгенерированный код избавляет от ручного парсинга и ошибок
• бинарный формат получается в разы компактнее JSON
• экономия на сети, CPU и мобильном трафике чувствуется сразу
Автор честно отмечает слабое место Protobuf — бинарность усложняет отладку и требует инструментов. Но это та цена, которую легко принять, если вам важны скорость, предсказуемость и типобезопасность всей системы.
📚 Читайте и комментируйте на Хабр.
@go_for_devs
😱 MinIO: развитие остановлено
Команда MinIO объявила, что проект уходит в чистый maintenance-mode. Никаких новых фичи, PR’ов и даже review существующих изменений.
Останутся только точечные фиксы критических уязвимостей (и то по ситуации).
Активное развитие теперь живёт в их enterprise-решении MinIO AIStor.
Такой вот Open Source :)
@go_for_devs
😎 Про новый GC в Go теперь уже в формате доклада
Мы недавно разбирали в отдельной статье, какие апдейты ждут сборщик мусора в Go 1.26 — и почему это одно из самых заметных улучшений последних релизов. Если вдруг ещё не читали, самое время наверстать.
А теперь к этому добавился и свежий доклад c GopherCon 2025: "Advancing Go Garbage Collection with Green Tea".
Теперь можно не только прочитать, но и посмотреть!
@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/
💡 Почему маленькие интерфейсы делают Go-код ощутимо лучше
Подготовили разбор о том, почему огромные интерфейсы в Go — это тихий архитектурный антипаттерн, который портит тесты, замедляет разработку и делает код хрупким. Автор идёт от практики: берёт реальный код, смотрит, как широкие контракты тянут за собой ненужные зависимости, и показывает, почему принцип разделения интерфейсов (тот самый ISP из SOLID) в Go работает почти автоматически — если ему не мешать.
Автор показывает всё на конкретном коде: сначала простой FileStorage, который вроде бы удобен… пока не нужно протестировать функцию, использующую всего один метод. Потом — S3-клиент из AWS SDK, где желание «обернуть всё интерфейсом» быстро приводит к монстру из десятков методов, который привязывает весь проект к одному определению.
Статья объясняет, как Go естественным образом подталкивает к маленьким интерфейсам: вы определяете контракт рядом с потребителем, оставляете только нужное поведение и получаете код, который проще тестировать, легче менять и труднее сломать случайным обновлением зависимостей.
Коротко: широкие интерфейсы — это технический долг, который маскируется под «архитектурную зрелость». Маленькие интерфейсы — это практичный, Go-шный путь к читаемому и поддерживаемому коду.
📚 Читать на Хабр: https://habr.com/ru/articles/967730/
🫡 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
😬 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 добавляет небольшой оверхед ради явной структуры и валидации.
npx @toon-format/cli и TypeScript-библиотека @toon-format/toon.
🥳 Состоялся релиз Go 1.26
В релиз вошли несколько заметных изменений:
1. Функция new теперь принимает выражение с начальным значением, так что вместо
x := int64(300)
ptr := &x
ptr := new(int64(300))
cgo снизили примерно на 30%, компилятор чаще размещает backing store для срезов на стеке.go fix переписан на базе Go analysis framework и получил несколько десятков «modernizers» — анализаторов с безопасными автоправками. Появился inline-анализатор для функций с директивой //go:fix inline.simd/archsimd для SIMD-операций, runtime/secret для затирания временных секретных данных и профиль goroutineleak в runtime/pprof.
🆕 Совсем скоро релиз Go 1.26 — и сегодня команда выложила go1.26rc2, второй release candidate
RC получился почти полностью «про безопасность»: в него вошли 6 фиксов с CVE.
В основном это DoS-кейсы и проблемы с неожиданным поведением тулчейна.
— archive/zip — суперлинейная индексация имён файлов позволяла повесить парсер на специально собранном архиве
— net/http — Request.ParseForm мог аллоцировать неограниченное количество памяти при большом числе параметров
— crypto/tls — Config.Clone больше не копирует автоматически сгенерированные session ticket keys; также при session resumption теперь учитывается срок действия всей цепочки сертификатов, а не только leaf.
@go_for_devs
🎄 Итоги года 4Devs 2025
На прошлой неделе Habr опубликовал итоги года — и наш проект попал в ТОП-2 среди UGC-авторов (независимых, не аффилированных с компаниями) и в ТОП-8 overall!
Учитывая, что активно публиковаться мы начали только в сентябре, результат за один квартал, на мой взгляд, более чем достойный. Проект изначально запускался как эксперимент — и теперь уже можно уверенно сказать, что эксперимент удался.
В следующем году постараемся как минимум сохранить текущие темпы, а как максимум — заметно их преумножить. Если вы следите только за одним из каналов проекта, напоминаю полный список наших ресурсов:
— @ai_for_devs — флагман проекта. Неудивительно, учитывая взрывной рост прикладного ИИ именно для разработчиков
— @go_for_devs — второй по популярности, но самый активный по вовлечённости
— @python_for_devs — канал, с которого всё началось, и этим он прекрасен
— @js_for_devs — здесь всё ещё впереди. Если вы из frontend-мира — добро пожаловать, догоним остальных 🙂
Суммарно за проектом уже следит более 6.5 тысяч человек!
Поздравляю всех с наступающим Новым годом и желаю профессионального роста и сильных результатов в 2026!
⚙️ Go + cgo + Docker: как вернуть воспроизводимую кросс-сборку
Хороший практичный разбор про то, что происходит с Go-проектом после появления cgo. Формально go build всё ещё работает, но на практике каждый разработчик начинает жить в своём окружении с набором флагов, версий библиотек и локальных костылей.
В статье простой, но рабочий выход: всю сборку вынести в Docker и рассматривать его как единое билд-окружение. Внутри контейнера явно задаются CC, CXX, AS и ldflags для каждой пары OS/arch, что позволяет из одного места собирать Linux, macOS и Windows бинарники, включая статическую линковку там, где это возможно.
Важно, что Docker используется без Dockerfile — берётся официальный golang-образ и напрямую запускается bash-скрипт. Это делает процесс легко воспроизводимым как для команды, так и для пользователей open source-проекта.
Подход не самый быстрый и не самый изящный, но он позволяет сделать локальную сборку идентичной продакшену, а cgo перестаёт быть источником проблем.
@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, Rust и Zig такие разные: ценности, компромиссы и назначение языков
3 языка будучи «похожими» на самом деле выражают три совершенно разные философии. Их можно сравнить не по фичам, а по ценностям и компромиссам, заложенным в дизайн.
Go: минимализм и корпоративная предсказуемость
• Язык намеренно маленький, «умещается в голове», жертвует выразительностью ради стабильности
• Новые фичи проходят через очень высокий порог: отсюда долгие 12 лет без дженериков
• Простой slice, скрытый рантайм и GC избавляют от размышлений о памяти
• Заточен под командную разработку, читаемость и предсказуемую конкурентность
Rust: максимализм и гарантия безопасности
• Огромное число концепций, трейт-систем, слоёв абстракций; высокая когнитивная плотность
• Идея «абстракции без накладных расходов» реализована буквально: безопасность без рантайма, через статические гарантии
• Сложен в обучении, но даёт сильнейшие гарантии и библиотечную экосистему без «страха чужого кода»
Zig: свобода, ручной контроль и анти-OOP
• Самый молодой из тройки, ещё сырой, но философски наиболее радикальный
• Полностью ручное управление памятью, выбор аллокатора как часть архитектуры
• Нет скрытой магии: ни неявных выделений, ни рантайма, ни динамического полиморфизма
• Стимулирует data-oriented дизайн и большие предсказуемые аллокации вместо «графа объектов»
• Ощущается дерзким «анархистским» языком для тех, кому хочется полного контроля и минимум абстракций
⚡️ Вышел GoLand 2025.3
В новом релизе JetBrains сделали упор на раннее выявление ошибок, работу с облачной инфраструктурой и ускорение повседневных операций.
Коротко — самое важное:
— Новый анализатор утечек ресурсов (файлы, коннекты, дескрипторы).
— Поддержка нескольких ИИ-агентов: теперь Junie + встроенный Claude Agent.
— Terraform встроен по умолчанию, работает прямо из коробки.
— Крупные улучшения Kubernetes-инструментов: CI/CD-флоу прямо в редакторе.
— Новая тема интерфейса Islands по умолчанию.
— Возможность открывать отдельные файлы без проекта.
— Полная поддержка golangci-lint fmt из версии 2.
— Существенный прирост производительности: меньше OOM-предупреждений, умнее индексирование, отзывчивее UI.
📚 Читайте и комментируйте на Хабр.
@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
🔍 Как Go-компилятор превращает ваш код в токены
Опубликовали отличный разбор того, с чего реально начинается компиляция Go — со сканера (или лексера). Того самого компонента, который посимвольно читает ваш код и превращает его в поток токенов.
Сканер в Go работает удивительно прямолинейно: видит букву — пытается идентификатор, сверяет с таблицей ключевых слов; видит + — решает, это +, ++ или +=; встречает перевод строки — вставояет точку с запятой.
Что занятно — у Go два сканера. Один из стандартной библиотеки (go/scanner), другой — тот, что реально кормит компилятор (src/cmd/compile/internal/syntax/scanner.go). И именно второй делает всю тяжёлую работу: буферизует вход, трекает позиции, прокручивает Unicode, следит за состоянием вставки ; и т.д.
В статье пошаговый разбор классического hello world. Хорошее чтиво.
@go_for_devs
💧 Симуляция воды на Go
Подготовили для вас перевод статьи Тима Литтла, где он на чистом Go и raylib-go собирает лёгкую симуляцию воды для 2D-игр. Без сложной физики и уравнений Навье—Стокса.
Под капотом — сетка из `Droplet`-ячееек, у каждой свой объём воды.
Дальше автор по шагам накручивает поведение:
🟣 Гравитация: капли падают вниз, пока есть свободное место;
🟣 Боковой поток: если низ забит — вода растекается влево и вправо;
🟣 «Давление»: остатки утекают по диагонали, заполняя пустоты;
🟣 Препятствия: вода огибает блоки, переливается через «платформы» и красиво стекает вниз.
В итоге, правда, получилась не реалистичная вода, а скорее классная симуляция песка) Отлично подходит для эффектов песка, лавы, воды из трубы или сыплющегося мусора в пиксельной игре.
Конечно, вряд ли пригодится завтра на работе, но выглядит прикольно)
@go_for_devs
🔥 Самая важная новость недели)
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 сегодня: что изменилось в 2025 году
Перевели подробный разбор того, как эволюционировала экосистема Go к 2025 году — от фреймворков и тестовых библиотек до инструментов для DevOps и AI-редакторов.
Общее впечатление после прочтения такое: за пять лет Go стал заметно популярнее, инструментов стало больше, AI-редакторов — тоже, но принципиально почти ничего не поменялось. Подходы остаются прежними.
Мы всё так же используем gin, net/http и GoLand. Разве что значительно выросла доля тех, кто предпочитает встроенный пакет testing — теперь им пользуются 60% разработчиков против 35% пять лет назад.
Интересы Go-сообщества тоже практически не изменились: те же Kubernetes, те же базы данных, те же сервисы для логирования.
И, пожалуй, это скорее плюс. Экосистема растёт вместе с количеством разработчиков, но без резких поворотов и кардинальных перемен, которые обычно вносят хаос и заставляют команды перестраивать процессы.
@go_for_devs
🐘 Kafka реально быстрая, но я возьму Postgres
Перевели довольно длинный, но приземлённый разбор: зачем большинству проектов вообще тащить Kafka и пять разных баз, если тот же Postgres спокойно закрывает типичные нагрузки. Автор не просто рассуждает — он гоняет бенчмарки и смотрит, насколько далеко можно уехать на одном Postgres в сценариях pub/sub и очередей.
Если коротко, то по мир можно поделить на два лагеря:
🟣 Первый — «резюме-дривен девелопмент»: берём модные стеки, потому что «так делают большие компании» и «это спрашивают на собесах», даже если реальная нагрузка — пара мегабайт в секунду.
🟣 Второй — те, кто начинают с базовых вещей и считают не только RPS, но и организационные издержки: новые системы надо изучать, мониторить, обновлять, поддерживать, и это обходится дороже, чем кажется. На этом фоне логика «просто используйте Postgres, пока не упрётесь в реальные лимиты» выглядит вполне рационально.
В бенчмарках Postgres выступает как и pub/sub, и очередь: десятки тысяч сообщений в секунду, мегабайты входящего/исходящего трафика, на относительно скромных инстансах и без экзотического тюнинга. Да, Kafka и спецочереди по-прежнему лучше оптимизированы под свои задачи и выигрывают на очень больших масштабах. Но до этих масштабов большинство систем просто не доходит — и в подавляющем числе кейсов упираться будете не в базу, а в продукт, команду или деньги.
Вместо «архитектуры как у Google» лучше думать в терминах минимально жизнеспособной инфраструктуры: взять Postgres и использовать его максимально просто и добавлять новые технологии только тогда, когда они реально нужны. Чем меньше компонентов — тем меньше точек отказа и меньше клейкого кода между ними.
Краткий вывод от статьи такой: начните с Postgres, держите стек простым, а к Kafka и прочим тяжёлым системам приходите только тогда, когда у вас действительно появятся проблемы их масштаба. Всё остальное — из серии «преждевременная оптимизация».
@go_for_devs
🥳 Go исполнилось 16 лет: главное о развитии языка и экосистемы
10 ноября языку Go стукнуло 16 лет с момента выхода в Open source — и команда подошла к дню рождения не с ностальгией, а с результатами.
Вот главное, что произошло вокруг именинника за последнее время:
🟣 К одному из самых заметных прорывов относится новый сборщик мусора Green Tea, который снижает накладные расходы на 10–40%. Для продакшн-сервисов это означает меньше пауз, стабильнее задержки и ощутимый выигрыш без каких-либо доработок в коде. Подробнее про него мы писали тут.
🟣 Не менее значимый апдейт — flight recorder для диагностики: он сохраняет последние миллисекунды жизни сервиса и позволяет понять, что случилось, даже если проблема проявилась спустя часы. Подробнее про него мы писали тут.
🟣 А ещё Go уверенно заходит в эпоху ИИ: официальный MCP SDK и интеграции в gopls формируют прочный фундамент для разработки агентных систем и инструментов прямо на Go.
Команда обещает, что это только начало — и обороты они точно снижать не собираются.
@go_for_devs