Дженерики в Go: Ваш дружелюбный гид по повторно используемому коду

В этом гайде рассказывается, что такое дженерики, как их использовать и зачем они нужны

👉 Читать

👉 @GolangPortal

От 19 часов до менее секунды: создание сверхбыстрого TCP-сканера на Go

Статья о том, как команда переписала свой сканер сети с обычного TCP-connect метода на «half-open» SYN-сканирование на языке и добилась сокращения времени проверки сети из 19 часов до менее чем одной секунды

Читайте здесь

👉 @GolangPortal

Understanding the Go compiler: The Parser

Статья объясняет, как парсер компилятора Go превращает поток токенов в абстрактное синтаксическое дерево (AST) с помощью рекурсивного спуска, разбирая ключевые функции и структуры на практических примерах

Читайте здесь

👉 @GolangPortal

Построение конвейера «производитель–потребитель» в Go с использованием горутин и каналов

Статья рассказывает, как с помощью языковых механизмов Go (горутин и каналов) построить конвейер «производитель–потребитель», чтобы параллельно обрабатывать тяжёлые CPU-задачи и при этом безопасно записывать результаты в базу данных без конкуренции за запись

Читайте здесь

👉 @GolangPortal

👨‍💻 Определите роль Go в своей AI архитектуре

В AI проектах Go лучше всего чувствует себя не в роли «я сам напишу модель», а в роли надежного каркаса вокруг моделей. Речь про сервисы, API, очереди, оркестрацию пайплайнов, интеграцию с другими системами.

Тяжелые вычисления и обучение обычно остаются на Python, C++ или готовых AI платформах, а Go берет на себя устойчивость, предсказуемое время ответа и нагрузку.

Допустим, у вас есть сервис с моделью на Python, поднятый через FastAPI или gRPC. Go слой выглядит как обычный HTTP или gRPC сервис, который:

• принимает запрос от клиента
• валидирует данные, обогащает контекст
• делает запрос к модельному сервису
• обрабатывает ответ, пишет логи и метрики
• возвращает результат пользователю

Где Go раскрывается по максимуму

— API слой и шлюзы

Go используют для API gateway и BFF (backend for frontend): высокая нагрузка, множество клиентов, разные типы аутентификации и трейсинг.

​AI здесь — всего лишь одна из зависимостей. Это позволяет не смешивать фронтовую и AI‑специфику.

— Оркестрация AI пайплайнов

Обработка данных, фичеринг, вызовы нескольких моделей по цепочке, запись результатов, ретраи, дедлайны — всё это удобно делать на Go в виде набора микросервисов либо централизованного оркестратора.

Go хорошо сочетается с:

• очередями (Kafka, RabbitMQ, NATS)
• workflow системами (Temporal, Cadence, Argo Workflows
• gRPC и protobuf для связи с Python сервисами.

— Реалтайм и стриминг

Если вам нужен стриминговый чат, онлайн‑анализ событий, веб‑сокеты или SSE поверх LLM — Go с его сетевой моделью и goroutine хорошо закроет эту задачу. Модель может отвечать стримом, а Go будет потоково прокидывать их клиенту, не блокируя остальную систему.

Что явно не стоит насильно тащить в Go

— обучение больших моделей и сложный

— эксперименты с фреймворками, где вся экосистема вокруг Python

— CUDA‑обвязка и кастомные GPU‑ядра без серьёзной причины

Удачная стратегия на 2026 год выглядит так: не превращать Go в ещё один ML язык, а использовать его как надёжный сервисный и оркестрационный слой вокруг AI.

🔹 Математика для разработки AI-моделей
🔹 Получить консультацию менеджера
🔹 Сайт Академии 🔹 Сайт Proglib

🐸 Библиотека Go-разработчика

#GoDeep

🔖System Programming Essentials with Go: System calls, networking, efficiency, and security practices with practical projects in Golang
Автор: Alex Rios (2024)

С помощью практических проектов вы освоите такие основные понятия, как файловый ввод-вывод, управление процессами и межпроцессное взаимодействие, чтобы автоматизировать задачи и эффективно взаимодействовать с системой. Вы погрузитесь в сетевое программирование на Go и приобретете навыки создания надежных распределенных приложений. Эта книга выходит за рамки основ, изучая такие современные методы, как ведение журналов и трассировка для всестороннего мониторинга приложений, и переходит к проектированию распределенных систем с помощью Go, чтобы подготовить вас к работе со сложными архитектурами. К концу этой книги вы станете уверенным системным программистом на Go, готовым создавать высокопроизводительные и безопасные приложения для современного мира.

#Go@programmist_of

👉@programmist_of

🔖gRPC Microservices in Go
Автор: Huseyin Babal (2023)

Книга научит вас создавать готовые к производству микросервисы с помощью Go и gRPC. В нем вы научитесь создавать эффективные API на Go, использовать gRPC для сетевого взаимодействия, а также развертываться в облаке и Kubernetes. Полезные примеры, в том числе полное веб-приложение для электронной коммерции, облегчают понимание каждой концепции. Вы также получите представление о тестировании, развертывании и эффективных практиках DevOps для микросервисов.

#Go@programmist_of

👉@programmist_of

Kafka устарела😳

Тут LinkedIn выкатили новый подход к Kafka.

Kafka стала де-факто стандартом для работы с большими данными.
Но LinkedIn рассказали про свою новую обвязку — Northguard и Xinfra. Давай разберем, что там за магия.

Короче, в чем соль? Почему им стало тесно в обычной Kafka?

У LinkedIn масштаб, который многим и не снился: сотни Kafka-кластеров, тысячи брокеров. И у них были классические «боли роста»:
🔵Клиенты были намертво привязаны к брокерам. Хочешь перенести топик на другой кластер для балансировки? Сорян, иди договаривайся с сотней команд, чтобы они поменяли у себя конфиги и перезапустились
🔵Операционный ад с репликацией. Стандартный инструмент для этого — MirrorMaker — превратился в их главного врага

Что такое MirrorMaker? Для тех, кто не в курсе: это стандартная утилита от Apache Kafka для репликации данных между разными Kafka-кластерами. Нужна для геораспределения или создания бэкап-кластера в другом дата-центре.

Проблема в том, что MirrorMaker — stateful (хранит в себе состояние оффсетов), сложен в управлении и жрал у них CPU как не в себя.

Что они придумали?

Они не стали пилить «убийцу Kafka». Вместо этого они построили над всем своим зоопарком кластеров абстракцию, очень похожую по философии на Control Plane в Kubernetes.

Представь: Kafka-кластеры — это твои worker-ноды, а новая система — это Kubernetes API Server + контроллеры, которые всем этим управляют.

1️⃣ Northguard — это и есть их Control Plane

Это «мозг» всей системы.

🔵Как работает: Разработчик больше не думает о физических кластерах. Он работает с логическим топиком. Например, profile-updates-logical
🔵Клиентское приложение при старте идет не в Kafka, а стучится по gRPC в Northguard Controller
🔵Контроллер лезет в свою базу метаданных (что-то типа их внутреннего ZooKeeper) и говорит клиенту: «Окей, твой логический топик profile-updates-logical сейчас физически лежит на кластере kafka-cluster-053 вот по этим адресам. Иди туда»
🔵Вся магия в миграции: Когда админам нужно перевезти топик (например, со старого железа на новое), они просто меняют эту запись в Northguard Controller. Клиенты автоматически подхватывают новый адрес и бесшовно, без даунтайма переключаются на новый кластер

2️⃣ Xinfra — движок репликации на стероидах

Это их замена для MirrorMaker

🔵Главная фишка — он stateless. Он не хранит оффсеты у себя. Как? Он просто использует стандартный механизм consumer groups в целевом кластере, чтобы коммитить туда прочитанные оффсеты. Упал инстанс Xinfra? Не беда, поднимаем новый, он читает последний коммит из Кафки и продолжает с того же места. Гениально и просто.
🔵За счет этого он легко горизонтально масштабируется: нужно больше пропускной способности — просто запускаешь больше его копий.
🔵Бонусом он умеет делать трансформацию сообщений и репартиционирование на лету во время репликации

Плюсы и минусы

➕
🔵Просто космос для эксплуатации: Миграция топиков без простоя и без дергания сотен команд.
🔵Экономия: Выкинули 1000+ хостов со старым MirrorMaker, высвободив кучу CPU.
🔵Надежность: Убрали единую точку отказа в репликации.

Аналогия с K8s не случайна: Control Plane (Northguard), который отвечает за управление, полностью отделен от Data Plane — слоя, где живут и перемещаются сами данные. В этот Data Plane входят и сами Kafka-кластеры (как хранилище), и Xinfra (как движок репликации между ними). В будущем под этот Control Plane можно будет подсунуть любую другую систему очередей, а клиенты этого не заметят.

〰️
В статье, конечно, сплошная история успеха. О минусах и подводных камнях внедрения такой махины они тактично молчат. Но очевидно, что разработка и внедрение такого слоя — это адски сложная задача.


Результат

Система уже в проде и ворочает триллионами сообщений в день. А теперь самое интересное:

LinkedIn заявили, что находятся на пути к тому, чтобы ЗАОПЕНСОРСИТЬ Northguard и Xinfra!🔥

Так что скоро, возможно, мы все сможем пощупать этот «Kubernetes для Kafka» своими руками