Forwarded from AI for Devs
This media is not supported in your browser
VIEW IN TELEGRAM
⚡️ JetBrains представила Air: новую агентную IDE
Компания выпустила Air — ADE (Agentic Development Environment), ориентированную на гибридную работу «разработчик + ИИ-агенты».
Это не просто чат с моделью внутри IDE, а отдельная среда разработки, где можно ставить задачи агентам, запускать их параллельно, контролировать изменения и коммитить результаты.
Air пока доступен в превью и работает только с одним агентом — Claude Agent, причём для использования требуется активная подписка Anthropic.
Версии для Windows и Linux обещают в 2026 году — сейчас приложение доступно только на macOS.
Сайт | Документация | Анонс в X | Анонс на Habr
@ai_for_devs
Компания выпустила Air — ADE (Agentic Development Environment), ориентированную на гибридную работу «разработчик + ИИ-агенты».
Это не просто чат с моделью внутри IDE, а отдельная среда разработки, где можно ставить задачи агентам, запускать их параллельно, контролировать изменения и коммитить результаты.
Air пока доступен в превью и работает только с одним агентом — Claude Agent, причём для использования требуется активная подписка Anthropic.
Версии для Windows и Linux обещают в 2026 году — сейчас приложение доступно только на macOS.
Сайт | Документация | Анонс в X | Анонс на Habr
@ai_for_devs
🔥8👍3⚡2🤯2😁1🤬1
🚀 Лучше, чем JSON: почему я перешёл на Protobuf
Опубликовали перевод статьи автора, который уже почти десятилетие не использует JSON в своих API и сознательно выбирает Protobuf.
JSON стал стандартом веба во многом случайно: человекочитаем, встроен в JavaScript, тривиален в инструментах и позволял «просто работать». Но при активной разработке он же создаёт хаос: отсутствующие поля, неверные типы, нет гарантий структуры, валидация вручную.
Protobuf же работает совсем иначе:
• контракт описывается в .proto — чёткие типы, стабильные теги
• сгенерированный код избавляет от ручного парсинга и ошибок
• бинарный формат получается в разы компактнее JSON
• экономия на сети, CPU и мобильном трафике чувствуется сразу
Автор честно отмечает слабое место Protobuf — бинарность усложняет отладку и требует инструментов. Но это та цена, которую легко принять, если вам важны скорость, предсказуемость и типобезопасность всей системы.
📚 Читайте и комментируйте на Хабр.
@go_for_devs
Опубликовали перевод статьи автора, который уже почти десятилетие не использует JSON в своих API и сознательно выбирает Protobuf.
JSON стал стандартом веба во многом случайно: человекочитаем, встроен в JavaScript, тривиален в инструментах и позволял «просто работать». Но при активной разработке он же создаёт хаос: отсутствующие поля, неверные типы, нет гарантий структуры, валидация вручную.
Protobuf же работает совсем иначе:
• контракт описывается в .proto — чёткие типы, стабильные теги
• сгенерированный код избавляет от ручного парсинга и ошибок
• бинарный формат получается в разы компактнее JSON
• экономия на сети, CPU и мобильном трафике чувствуется сразу
Автор честно отмечает слабое место Protobuf — бинарность усложняет отладку и требует инструментов. Но это та цена, которую легко принять, если вам важны скорость, предсказуемость и типобезопасность всей системы.
📚 Читайте и комментируйте на Хабр.
@go_for_devs
🔥7👍6❤3😁2
This media is not supported in your browser
VIEW IN TELEGRAM
⚡️ Вышел GoLand 2025.3
В новом релизе JetBrains сделали упор на раннее выявление ошибок, работу с облачной инфраструктурой и ускорение повседневных операций.
Коротко — самое важное:
— Новый анализатор утечек ресурсов (файлы, коннекты, дескрипторы).
— Поддержка нескольких ИИ-агентов: теперь Junie + встроенный Claude Agent.
— Terraform встроен по умолчанию, работает прямо из коробки.
— Крупные улучшения Kubernetes-инструментов: CI/CD-флоу прямо в редакторе.
— Новая тема интерфейса Islands по умолчанию.
— Возможность открывать отдельные файлы без проекта.
— Полная поддержка
— Существенный прирост производительности: меньше OOM-предупреждений, умнее индексирование, отзывчивее UI.
📚 Читайте и комментируйте на Хабр.
@go_for_devs
В новом релизе JetBrains сделали упор на раннее выявление ошибок, работу с облачной инфраструктурой и ускорение повседневных операций.
Коротко — самое важное:
— Новый анализатор утечек ресурсов (файлы, коннекты, дескрипторы).
— Поддержка нескольких ИИ-агентов: теперь Junie + встроенный Claude Agent.
— Terraform встроен по умолчанию, работает прямо из коробки.
— Крупные улучшения Kubernetes-инструментов: CI/CD-флоу прямо в редакторе.
— Новая тема интерфейса Islands по умолчанию.
— Возможность открывать отдельные файлы без проекта.
— Полная поддержка
golangci-lint fmt из версии 2.— Существенный прирост производительности: меньше OOM-предупреждений, умнее индексирование, отзывчивее UI.
📚 Читайте и комментируйте на Хабр.
@go_for_devs
👍10❤4🔥2🥰1🤔1🤯1
В Go утечки ресурсов часто выглядят как мелочь: не закрыли тело HTTP-ответа, забыли
GoLand 2025.3 получил анализ утечек, который ловит такие проблемы прямо во время написания кода.
В новой статье разбираются реальные кейсы, где один пропущенный
Инструмент отслеживает все пути выполнения, включая пользовательские типы с
📚 Читайте и комментируйте на Хабр.
@go_for_devs
defer rows.Close(), оставили открытый файл. Но под нагрузкой это может привести к падению сервиса. GC тут не спасает: он чистит память, а не системные дескрипторы.GoLand 2025.3 получил анализ утечек, который ловит такие проблемы прямо во время написания кода.
В новой статье разбираются реальные кейсы, где один пропущенный
Close() приводил к росту памяти, ошибкам can’t assign requested address и полному исчерпанию SQL-коннекшенов из-за единственного NULL в таблице.Инструмент отслеживает все пути выполнения, включая пользовательские типы с
io.Closer, и подсвечивает, где ресурс может остаться открытым.📚 Читайте и комментируйте на Хабр.
@go_for_devs
Хабр
Анализ утечек ресурсов в Go: реальные кейсы и их решение
Команда Go for Devs подготовила перевод статьи о том, как GoLand помогает разработчикам вовремя находить и устранять утечки ресурсов. Файлы, соединения, HTTP-ответы, SQL-строки — всё это может...
👍11🔥4❤2🤔1🤯1
3 языка будучи «похожими» на самом деле выражают три совершенно разные философии. Их можно сравнить не по фичам, а по ценностям и компромиссам, заложенным в дизайн.
Go: минимализм и корпоративная предсказуемость
• Язык намеренно маленький, «умещается в голове», жертвует выразительностью ради стабильности
• Новые фичи проходят через очень высокий порог: отсюда долгие 12 лет без дженериков
• Простой slice, скрытый рантайм и GC избавляют от размышлений о памяти
• Заточен под командную разработку, читаемость и предсказуемую конкурентность
Rust: максимализм и гарантия безопасности
• Огромное число концепций, трейт-систем, слоёв абстракций; высокая когнитивная плотность
• Идея «абстракции без накладных расходов» реализована буквально: безопасность без рантайма, через статические гарантии
• Сложен в обучении, но даёт сильнейшие гарантии и библиотечную экосистему без «страха чужого кода»
Zig: свобода, ручной контроль и анти-OOP
• Самый молодой из тройки, ещё сырой, но философски наиболее радикальный
• Полностью ручное управление памятью, выбор аллокатора как часть архитектуры
• Нет скрытой магии: ни неявных выделений, ни рантайма, ни динамического полиморфизма
• Стимулирует data-oriented дизайн и большие предсказуемые аллокации вместо «графа объектов»
• Ощущается дерзким «анархистским» языком для тех, кому хочется полного контроля и минимум абстракций
📚 Читайте и комментируйте на Хабр.
@go_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡7🔥5❤3👍1🤔1
Наткнулись и перевели большую и очень интересную статью про гонки данных в Go от человека, который годами находит и чинит их в реальных системах.
Автор показывает не учебные примеры, а живые кейсы из продакшена:
• Неявный захват внешних переменных в замыканиях, где один пропущенный
: превращает локальную переменную в общую•
http.Client, который в документации объявлен потокобезопасным, но внезапно ломается, если конкурентно менять его поля• Мьютексы, которые формально используются корректно, но живут меньше, чем данные, которые должны защищать
• И стандартная библиотека, где
map, bytes.Buffer и другие типы вовсе не рассчитаны на конкурентный доступ, хотя это не всегда очевидно из APIRace detector сильно помогает, но он не всесилен: часть гонок проходит мимо, а симптомы могут проявляться только под нагрузкой или в CI.
Интересна и более общая мысль статьи: если такие ошибки регулярно допускают опытные инженеры, значит проблема не только в внимательности. Неявные замыкания, мелкое копирование структур с ссылочными полями, отсутствие встроенного
Clone(), слабая документация по потокобезопасности — всё это увеличивает вероятность гонок, даже в аккуратно написанном коде.Если язык и экосистема делают гонки данных слишком лёгкими, рано или поздно за это заплатит продакшн.
@go_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
1000 и один способ угробить программу из-за гонки данных в Go
Команда Go for Devs подготовила перевод статьи о самых коварных и трудноуловимых гонках данных в Go. Автор показывает на реальных примерах, как даже опытные разработчики легко попадают в ловушки...
👍8❤3🔥3🤔1🤬1😢1
🚀 1 млн запросов в секунду на Go: уроки продакшена
Если у вас read-heavy API, бить по базе или Redis на миллион RPS — заведомо проигрышная стратегия.
Ключевая идея — распределённый In-Memory Cache, синхронизируемый через события:
🟠 Write-сервис пишет в БД и публикует обновления
🔵 Read-сервисы подписываются на события и обновляют локальный кэш
🟡 Чтение обслуживается напрямую из памяти, без I/O
В результате один pod выдерживает ~60k RPS, а миллион запросов закрывается менее чем 20 pod’ами.
📚 Практика, цифры и код — в новой статье на Хабре.
@go_for_devs
Если у вас read-heavy API, бить по базе или Redis на миллион RPS — заведомо проигрышная стратегия.
Ключевая идея — распределённый In-Memory Cache, синхронизируемый через события:
В результате один pod выдерживает ~60k RPS, а миллион запросов закрывается менее чем 20 pod’ами.
📚 Практика, цифры и код — в новой статье на Хабре.
@go_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤3🔥3
— В статике 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
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Go (Golang) vs TypeScript Performance Benchmark (2026)
Go vs TypeScript Speed Performance Benchmark.
👨💼 Mentorship/On-the-Job Support/Consulting - https://calendly.com/antonputra/youtube or [email protected]
👀 Check out recommendations from my previous clients - https://www.linkedin.com/in/anton-putra/deta…
👨💼 Mentorship/On-the-Job Support/Consulting - https://calendly.com/antonputra/youtube or [email protected]
👀 Check out recommendations from my previous clients - https://www.linkedin.com/in/anton-putra/deta…
👍10🔥3❤2😁1
⚙️ Go + cgo + Docker: как вернуть воспроизводимую кросс-сборку
Хороший практичный разбор про то, что происходит с Go-проектом после появления cgo. Формально
В статье простой, но рабочий выход: всю сборку вынести в Docker и рассматривать его как единое билд-окружение. Внутри контейнера явно задаются
Важно, что Docker используется без Dockerfile — берётся официальный
Подход не самый быстрый и не самый изящный, но он позволяет сделать локальную сборку идентичной продакшену, а cgo перестаёт быть источником проблем.
@go_for_devs
Хороший практичный разбор про то, что происходит с Go-проектом после появления cgo. Формально
go build всё ещё работает, но на практике каждый разработчик начинает жить в своём окружении с набором флагов, версий библиотек и локальных костылей.В статье простой, но рабочий выход: всю сборку вынести в Docker и рассматривать его как единое билд-окружение. Внутри контейнера явно задаются
CC, CXX, AS и ldflags для каждой пары OS/arch, что позволяет из одного места собирать Linux, macOS и Windows бинарники, включая статическую линковку там, где это возможно.Важно, что Docker используется без Dockerfile — берётся официальный
golang-образ и напрямую запускается bash-скрипт. Это делает процесс легко воспроизводимым как для команды, так и для пользователей open source-проекта.Подход не самый быстрый и не самый изящный, но он позволяет сделать локальную сборку идентичной продакшену, а cgo перестаёт быть источником проблем.
@go_for_devs
Хабр
Go, cgo и Docker: практичная кросс-платформенная сборка
Команда Go for Devs подготовила перевод статьи о том, как упростить сборку Go-проектов с cgo, используя Docker. Авторы на реальном примере показывают, как избавиться от платформенной боли, сложных...
👍6🔥3❤2
⚡️ Две короткие новости про Claude Code
Во-первых, Anthropic добавили нативную поддержку LSP — включая Go. Агент теперь работает не через
Во-вторых, на новогодние праздники удвоили лимиты для подписок Pro и Max — с сегодняшней ночи и до конца года.
Если до сих пор не пробовали AI-помощников разработчика в деле, то стоит начать. В 2026 это точно станет БАЗОЙ.
@go_for_devs
Во-первых, Anthropic добавили нативную поддержку LSP — включая Go. Агент теперь работает не через
grep и эвристики, а видит семантику кода как IDE: go-to-definition, ссылки, типы, символы. Для больших кодовых баз и рефакторинга — качественный скачок.Во-вторых, на новогодние праздники удвоили лимиты для подписок Pro и Max — с сегодняшней ночи и до конца года.
Если до сих пор не пробовали AI-помощников разработчика в деле, то стоит начать. В 2026 это точно станет БАЗОЙ.
@go_for_devs
👍7🔥3💯3🤔1
Forwarded from AI for Devs
На прошлой неделе Habr опубликовал итоги года — и наш проект попал в ТОП-2 среди UGC-авторов (независимых, не аффилированных с компаниями) и в ТОП-8 overall!
Учитывая, что активно публиковаться мы начали только в сентябре, результат за один квартал, на мой взгляд, более чем достойный. Проект изначально запускался как эксперимент — и теперь уже можно уверенно сказать, что эксперимент удался.
В следующем году постараемся как минимум сохранить текущие темпы, а как максимум — заметно их преумножить. Если вы следите только за одним из каналов проекта, напоминаю полный список наших ресурсов:
— @ai_for_devs — флагман проекта. Неудивительно, учитывая взрывной рост прикладного ИИ именно для разработчиков
— @go_for_devs — второй по популярности, но самый активный по вовлечённости
— @python_for_devs — канал, с которого всё началось, и этим он прекрасен
— @js_for_devs — здесь всё ещё впереди. Если вы из frontend-мира — добро пожаловать, догоним остальных 🙂
Суммарно за проектом уже следит более 6.5 тысяч человек!
Поздравляю всех с наступающим Новым годом и желаю профессионального роста и сильных результатов в 2026!
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Хабр — Итоги 2025
Привет, Хабр! Ну, как настроение? Кажется, что мир начинает вращаться с какой-то практически неуловимой для человеческого внимания скоростью: ИИ, нейрослоп, мошенники, зоопарк хакеров найма, утечки,...
👍10🔥4❤2
⚡️ В Go 1.26 (релиз которого планируется в феврале) добавят поддержку SIMD
SIMD (Single Instruction, Multiple Data) — это способ выполнять одну инструкцию сразу над набором данных. Проще говоря, процессор может сложить, умножить или сравнить сразу несколько чисел за один такт. Это критично для задач вроде обработки массивов, графики, ML, криптографии и любых data-heavy пайплайнов — прирост производительности там может быть кратным.
В следующей версии Go появится новый низкоуровневый пакет
Подход разумный. SIMD сильно зависит от железа, и преждевременный «универсальный» интерфейс легко может стать ошибкой.
@go_for_devs
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 — после серии прототипов и экспериментов с производительностью и переносимостью.
@go_for_devs
👍18🔥6❤2🤯1
RC получился почти полностью «про безопасность»: в него вошли 6 фиксов с CVE.
В основном это DoS-кейсы и проблемы с неожиданным поведением тулчейна.
—
archive/zip — суперлинейная индексация имён файлов позволяла повесить парсер на специально собранном архиве—
net/http — Request.ParseForm мог аллоцировать неограниченное количество памяти при большом числе параметров—
crypto/tls — Config.Clone больше не копирует автоматически сгенерированные session ticket keys; также при session resumption теперь учитывается срок действия всей цепочки сертификатов, а не только leaf.@go_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8👏2🔥1😢1
🔥 Перевели хороший разбор про атомарные операции и мьютексы в Go — на примерах и с бенчмарками, без абстрактной теории.
Коротко:
Проблемы начинаются, как только логика перестаёт быть «одна операция — одно поле». Атомарные операции защищают ровно одну инструкцию. Последовательность
Из статьи я бы вынес одно практическое правило. Начинать стоит с мьютекса.
Атомарные операции — это инструмент точечной оптимизации, когда:
* объект — одно значение или независимые счётчики,
* нет сложных инвариантов,
* выигрыш подтверждён измерениями, а не ощущениями.
Во всех остальных случаях простота и локальная очевидность кода обычно оказываются важнее разницы между 30 и 100 наносекундами.
📚 Читать на Хабр: https://habr.com/ru/articles/986732/
Коротко:
sync/atomic действительно быстрее. В простом кейсе с одним общим счётчиком атомики дают ~3× выигрыш по времени операции по сравнению с sync.RWMutex. Это ожидаемо: одна инструкция CPU против захвата блокировки, пусть даже с быстрым путём в рантайме Go.Проблемы начинаются, как только логика перестаёт быть «одна операция — одно поле». Атомарные операции защищают ровно одну инструкцию. Последовательность
прочитать → проверить → записать уже не атомарна. Для корректности приходится переходить к CAS-циклам, ретраям, лимитам попыток. Код быстро обрастает условиями, и цена ошибки становится выше, чем выигрыш в наносекундах.Из статьи я бы вынес одно практическое правило. Начинать стоит с мьютекса.
Атомарные операции — это инструмент точечной оптимизации, когда:
* объект — одно значение или независимые счётчики,
* нет сложных инвариантов,
* выигрыш подтверждён измерениями, а не ощущениями.
Во всех остальных случаях простота и локальная очевидность кода обычно оказываются важнее разницы между 30 и 100 наносекундами.
📚 Читать на Хабр: https://habr.com/ru/articles/986732/
Хабр
Атомарные операции против мьютексов в Go: когда скорость становится проблемой
Команда Go for Devs подготовила перевод статьи о том, действительно ли атомарные операции всегда быстрее и лучше мьютексов в конкурентном коде. Автор разбирает реальные сценарии, показывает...
👍7🔥7❤2💯1
Помните, осенью мы писали про запуск опроса Go Survey 2025. Так вот, вчера команда Go опубликовала результаты!
В опросе приняли участие 5 379 разработчиков.
Подробнее с результатами опроса можно ознакомиться на Habr.
@go_for_devs
В опросе приняли участие 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% софт вообще не использует ИИ.
Подробнее с результатами опроса можно ознакомиться на Habr.
@go_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥2⚡1🤔1