Go *

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 раз — и объясняет, почему это почти магия, но с нюансами.

Всем привет!

Не так давно я выкладывал RoadMap для самостоятельного изучения Go. Но во время обучения всегда встаёт важный вопрос: «А что учить дальше и на каком я уровне?».

Чтобы закрыть и его, я подготовил логичное продолжение — таблицу с вопросами и темами для самопроверки по грейдам (Junior, Middle, Senior).

Самый дешёвый билет далеко не всегда лучший для пользователя. Люди готовы доплатить за удобное время вылета, нормальный аэропорт или отсутствие ночной пересадки. Но если выдачу сортировать только по цене, оптимальные варианты оказываются глубоко внизу — и часть пользователей просто уходит к конкурентам.

Чтобы закрыть эту проблему, в Авиасейлс решили внедрить ML-скоринг и ранжировать билеты по вероятности покупки. На практике задача оказалась гораздо сложнее: разные источники данных у аналитиков и бэкенда, training-inference skew, провалы в нефункциональных требованиях и неожиданный рост latency.

Мост для тех кто привык к Systemd. Без эмуляции, без Systemd-зависимостей. Только переводит команды.

Команда Go for Devs подготовила перевод k8s-1m — кейса о том, как не догадки, а измерения двигают пределы Kubernetes. Ключевые идеи: изоляция QPS по типам ресурсов, смягчение гарантий хранения для эфемерных данных, и шардирование планировщика. Полезно всем, кто проектирует крупные кластеры или хочет работать с ними.