Go *

Всем привет! Меня зовут Макс Теричев. Я старший инженер по разработке ПО в YADRO. В первый день работы в компании меня отправили пройти Go Tour. После этого я приступил к работе по автоматизации тестирования Control Path сервисов в СХД. Чтобы увеличить их тестовое покрытие, был создан специальный фреймворк, который интегрировал написание тестов в процесс разработки. Что входит в этот подход, насколько дорого обходятся ошибки в разработке систем хранения данных и какие два вида мотивации здесь работают — читайте под катом.

Асинхронность — слово, от которого у разработчиков дергается глаз и теплеет сердце. Корутины, горутины, event loop, трэдпулы — за этими терминами скрывается целая философия, меняющая взгляд на то, как писать высоконагруженные системы.

Привет, Хабр! Меня зовут Дмитрий Буров и я Golang-разработчик, а также лидер Go-сообщества в Lamoda Tech. В IT свитчнулся из военного дирижера. В коммерческой  разработке — более 10 лет, начинал как фуллстек-разработчик на стеке JS, PHP, CSS, а последние шесть пишу только на Go. В этой статье по мотивам моего доклада для GolangConf расскажу про асинхронность и её роль в современных высоконагруженных системах. Разберём исторический аспект, концепцию и реализацию корутин в разных языках, эволюцию асинхронных подходов, сравним корутины и горутины, выясним, зачем Go добавил в рантайм пакет coro и чем это может обернуться.

Всем привет! Меня зовут Яна Курышева, и я тимлид одной из команд разработки бэкенда в Спортсе’’.

Мы – спортивное медиа. Наш продукт – это сайт и приложения со спортивной статистикой, новостями, редакционным и пользовательским контентом, пушами, рекомендациями и комментариями.

Чтобы вся система оставалась управляемой, мы активно используем трейсинг с помощью Elastic APM. Но существующие библиотеки не учитывали специфику нашей архитектуры и не решали всех задач.

В этой статье я поделюсь, как мы справились с задачей сбора трейсинга из старых монолитов и реализовали собственный APM-прокси.

JSON, YAML, TOML, HCL - за последние годы человечество успело изобрести десяток языков для конфигурации.
Каждый обещал быть "простым", "удобным" и "читаемым человеком".
Но по факту - все они страдают от одних и тех же проблем: шумный синтаксис, хрупкие отступы, бесконечные кавычки и отсутствие элементарных возможностей вроде модульности и слияния конфигов.

Пора перестать с этим мириться и сделать конфигурации наконец человеческими.

API.

Это слово звучит в каждой IT-статье, в каждой вакансии, в каждом разговоре разрабов. Но когда гуглишь, что это, вываливается тонна заумных определений про «программные интерфейсы приложений», от которых мозг плавится.

Так что сегодня объясню, что такое API, так, что ты точно поймешь: на простых примерах, интересно, да еще и с крутой графикой. Уже через несколько минут ты будешь великолепно знать, что такое API и как создать свой собственный.

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

Эта статья по мотивам моего доклада на Golang Conf X 2025 о болях шаблонного кода и вариантах их решения с помощью препроцессинга на базе стандартного тулчейна Go. В тексте не будет сравнения с препроцессорами в других языках и морально-этической оценки решения.

BBRv3, FEC и QUIC: как мы удержали jitter <1 мс и стабилизировали RU↔EU.

Мы стабилизировали QUIC на реальных RU↔EU трассах: jitter <1 мс PoP↔PoP, P50 ~20–21 мс RU↔EU (end-to-end). Помогли BBRv3 с динамическим pacing, HTTP/3 Datagrams/MASQUE (RFC 9297/9298/9484) и экспериментальный FEC. На профиле 5% потерь при включённом FEC видим ~+10% goodput (*recovery валидируем group-aligned тестом*). Ниже — методика, цифры и репликация. Замеры — для наших RU↔EU путей (ноябрь 2025), на других трассах цифры могут отличаться. Все тесты проводились на реальных Edge PoP узлах CloudBridge (Moscow, Frankfurt, Amsterdam) с использованием собственного инструмента quic-test.

Привет, Хабр!

Знаете это чувство, когда оборудование есть, мониторинг есть, а их совместная работа — нет? Именно так мы ощутили себя, когда столкнулись с IBM Storwize в экосистеме Zabbix. «Из коробки» поддержка отсутствует, а костыли в виде скриптов и UserParameters работают так, что хочется плакать:

Важность хорошей структуризации проекта могут недооценивать только совсем уж начинающие программисты. Сопровождение и развитие проекта с непродуманной структурой кода со временем превращается в сущий ад. Тут выплывают и проблемы со связанностью модулей и проблемы с плохой читабельностью и экспотенциально растущая трудоемкость развития проекта. Но всякая структура должна подчиняться некой логической концепции. И тут появляется великое поле для холиваров.

🧠 Система типов и интерфейсы в Go — это не просто о struct и interface{}.
Это про то, как язык заставляет проектировать надёжные, безопасные и предсказуемые системы.
В статье — от основ статической типизации до тонкостей работы интерфейсов, type assertion и generics.

В статье разбираем:
🔹 Как работает система типов Go и почему интерфейсы — это не классы.
🔹 Что такое type embedding и interface satisfaction.
🔹 Как использовать пустой интерфейс (interface{}) безопасно.
🔹 Чем опасны type assertions и где лучше применять type switch.
🔹 Как работают Generics (Go 1.18+) и как они сочетаются с интерфейсами.
🔹 Почему вызовы через интерфейсы влияют на производительность, и как это профилировать.
🔹 Где проходят границы между гибкостью и безопасностью типов.

На моих трансляциях лайв-кодинга постоянно всплывает этот вопрос. Проговаривал много раз, но если записать ответ, то дальше можно просто выдавать ссылку.

🌀 Конкурентность в Go: горутины и каналы — просто о сложном

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

В статье разберём:
✅ Что такое горутины и как Go управляет миллионами их одновременно.
✅ Как работают каналы и зачем они нужны для безопасного обмена данными.
✅ Как планировщик Go (GMP-модель) распределяет нагрузку между потоками.
✅ Типичные ошибки: deadlock, race condition, блокировки и как их избегать.
✅ Практические примеры — от простых пайплайнов до паттернов Fan-in/Fan-out.

Странно писать про форк open-source проекта для ушедшего в историю Docker Swarm. Но после Millau остался ещё один гештальт - периодические задачи. Посмотрел на Ofelia и Swarm-cronjob, их звезды, обновления, количество незакрытых репортов. Попытался связаться с автором - тишина. Так что с чистой совестью взял код и добавил недостающее. Получилась Cirona - Swarm-cronjob с телеметрией и дашбордами.

Уже начало ноября, и мои парсеры давно собрали свежие данные. Сегодня я поделюсь анализом обновления рейтинга и новостями проекта...

В этой статье я расскажу вам, как наша команда — «жыбий рыр» участвовала в хакатоне от DDOS‑GUARD

Рассмотрим, какой кейс мы выбрали, покажу, к какой реализации пришли и покажу наше решение, а в конце подведем итоги.

Первый Docker-образ для моего Go-приложения весил 1.92 GB. Для микросервиса на 100 строк — абсурдно. Решил разобраться, куда именно уходит место и как добиться максимально лёгкого образа.

Команда Go for Devs подготовила перевод статьи о новом экспериментальном сборщике мусора Green Tea, появившемся в Go 1.25. Он уже используется в Google и показывает снижение затрат CPU на GC до 40%. Разбираемся, почему это не просто оптимизация, а новый уровень эффективности.

Привет, Хабр!

Представьте: клиент отправил важный POST-запрос (например, создание заказа или списание денег), но из-за сетевого сбоя не получил ответ. Не зная, что на сервере операция уже выполнилась, клиент пробует повторить запрос. Если бэкенд не подготовлен к таким дублям, итог может быть печальным: мы создадим две одинаковые записи вместо одной или, хуже того, спишем деньги с пользователя два раза. Как этого избежать? Правильный ответ — реализовать идемпотентность в API.

Кхм. Громковатый заголовок, но я всё объясню.

Итак, у меня был сервис. Обычная молотилка данных, каждый с такой хотя бы раз да сталкивался - что-то на входе, что-то на выходе, а внутри походы в базу, HTTP-вызовы, шаблоны, скриптовая логика... В общем, много всякого.

Ну, ладно, тут стоит сразу уточнить, что сервис с особенностями - молотилка данных устроена так, что пытается работать с разными форматами на входе и выходе, а внутри держать всё в одном представлении. Но вот из-за этой потребности работать с разным, внутреннее представление это - мапы, слайсы, мапы в слайсах, слайсы в мапах, да ещё и из всех щелей торчит куча метрик.

Поэтому вот такая картина потребления памяти меня до недавних пор особо не смущала:

Команда Go for Devs подготовила перевод статьи о том, как memory maps (mmap) обеспечивают молниеносный доступ к файлам в Go. Автор показывает, что замена обычного чтения и записи на работу с памятью может ускорить программу в 25 раз — и объясняет, почему это почти магия, но с нюансами.