Golang

👣 Zero-copy в Go: маленькая обёртка может убить быстрый путь В AI-инфраструктуре постоянно гоняются большие файлы: датасеты, веса моделей, артефакты, логи, чанки для inference-сервисов. В таких местах лишнее копирование быстро превращается в CPU bill. В Go есть приятный fast path: io.Copy(conn, file) для *os.File -> *net.TCPConn может использовать sendfile(2). Данные идут из page cache в socket buffer без прокидывания через userspace. Проблема появляется, когда файл заворачивают в свой io.Reader для метрик, логирования или подсчёта байтов. Тип *os.File скрывается, Go больше не видит возможность включить sendfile, и передача откатывается в обычный цикл read -> write. В статье показан сильный контраст: raw-вариант сделал около 2 972 syscall, wrapped-вариант около 131 093 syscall на том же объёме данных. CPU cost вырос примерно в 3.4 раза на GiB. io.LimitReader fast path не ломает, потому что runtime умеет его распаковывать. Для TCP-to-TCP прокси похожий эффект даёт splice(2), если обе стороны остаются настоящими *net.TCPConn. В data path для больших файлов не стоит бездумно оборачивать Reader и Writer. Если обёртка нужна, сохраняйте optional interfaces вроде io.WriterTo и io.ReaderFrom. Проверка тоже простая- strace -c. Видите sendfile или splice, быстрый путь жив. Видите пачки read/write, значит CPU грузится сильнее из-за лишней абстракции. https://segflow.github.io/post/zero-copy-sendfile-splice/ @Golang_google

👣 Tonic для Go-разработчиков OpenAPI 3.2 генератор, который не заставляет писать Swagger-комменты руками. Вместо этого Tonic через reflect читает роуты, структуры, `json`-теги и `binding`-валидации, а потом собирает документацию прямо из кода. Поддерживает Chi, Echo, Fiber и Gin. Зачем это нужно: • меньше ручной синхронизации • меньше устаревших Swagger-комментов • документация ближе к реальному API • можно поднять Swagger UI / ReDoc / Scalar / RapiDoc https://github.com/phucvinh57/tonic/ @Golang_google

Go-разработчики, идём по барам с 2ГИС! 16 июля, 18:00, Нижний Новгород В программе три доклада, бархоппинг и разгон факапов.

Бархоппинг — это маршрут по барам. В каждом месте вас ждут мини-задачка и бокал чего‑то вкусного.

Уже чувствуете запах крафта? Тогда скорее регистрируйтесь! В заявке обязательно поделитесь каким-нибудь фэйлом. Лучшие обсудим в финале, посмеёмся над собой и поучимся у других

⚡️ `nixos-cli` заменяет разрозненные инструменты NixOS вроде `nixos-rebuild` единым командным интерфейсом. * Drop-in замена для nixos-rebuild и других стандартных NixOS-скриптов * TUI для управления generations и предпросмотра options * Wrapped и unwrapped варианты Ix-пакета, чтобы избежать лишних rebuild * Интеграционные тесты через pkgs.testers.runNixOSTest https://github.com/nix-community/nixos-cli

goldr (Go Layout-Driven Router) Server-first, HTML-first, нативный для HTMX фреймворк на Go для создания веб-приложений, которые остаются понятными, легко запускаются и удобно меняются по мере роста проекта. #golang https://github.com/mobiletoly/goldr @Golang_google

👣 M:N concurrency - это одна из причин, почему Go, Tokio, Erlang и Java Loom могут держать огромную конкурентность без миллиона тяжёлых OS-thread. Идея простая: M лёгких задач в user-space работают поверх N настоящих kernel threads Не один поток на всё, как в старых green threads. И не один OS-thread на каждую задачу, как в классической 1:1 модели. Runtime сам решает, какую goroutine, task или virtual thread запустить на доступном системном потоке. Пока одна задача ждёт I/O, scheduler паркует её и отдаёт поток другой задаче. В этом вся магия: • дешёвые задачи • меньше переключений через ядро • масштабирование до огромного числа соединений • work stealing • event loop • runtime scheduler вместо хаоса из тысяч потоков M:N — это не синтаксис async/await и не «фича Go». Это фундаментальная модель, на которой строится современная высоконагруженная конкурентность. https://0xkiire.com/mn-concurrency-model/

🚀 Писать код и проектировать архитектуру сервиса — это разные навыки. Именно на этом переходе многие Go-разработчики застревают между Middle и Senior. Можно уверенно писать код, знать фреймворки, библиотеки и инфраструктуру. Но когда бизнес-логика начинает расползаться по хендлерам, use case, репозиториям и DTO, появляются дублирование, хрупкие тесты с кучей моков и страх менять код — быстро становится понятно, что одного умения писать код уже недостаточно. 🔥 7 июля стартует курс по Domain-Driven Design и Clean Architecture на Go. Это не курс про то, как собрать систему из десятков микросервисов. Фокус — на архитектуре внутри одного сервиса: как организовать код так, чтобы бизнес-логика была понятной, изолированной и готовой к изменениям. За 1,5 месяца ты научишься: — проектировать предметную область, а не просто копировать структуру базы данных; — выделять Aggregate, Entity и Value Object; — работать с Domain Events и Domain Service; — строить сервисы по принципам Clean Architecture; — отделять бизнес-логику от HTTP, gRPC, Kafka, БД и других деталей реализации; — писать тесты на поведение системы, а не на набор моков. 📦 Практика занимает 80% курса. Ты разработаешь полноценный сервис диспетчеризации заказов и получишь рабочий шаблон микросервиса, который сможешь использовать в своей работе и команде. Курс ведёт Кирилл Ветчинкин — архитектор Авито, автор архитектурного шаблона микросервиса в СберМаркете, спикер Highload++, ArchDays, Podlodka и других крупных IT-конференций. 🎁 Первый модуль доступен бесплатно. В нём разбираются типичные причины, по которым кодовая база со временем становится сложной для изменений, а также подходы, которые помогают удерживать архитектуру сервиса под контролем по мере роста проекта. 👉 Посмотри первый модуль и оцени, насколько этот подход подходит для твоих задач: https://microarch.ru/courses/ddd/languages/go?utm_source=posev&utm_medium=erid:2VtzqvzcFN1&utm_campaign=1 Реклама. ИП Ветчинкин К.Е. ИНН: 773376451099 Erid: 2VtzqvzcFN1

👣 OpenComputer - облачные компьютеры для AI-агентов. Полноценная Linux VM для агентов. С реальной файловой системой, root-доступом, persistent state и возможностью продолжить работу с того же места. То есть это ближе к удалённому ноутбуку для агента: • VM не умирает после таймаута • состояние сохраняется между сессиями • можно делать checkpoints и откатываться назад • можно поднимать preview URL для приложений • агент работает рядом с файлами и кодом, без лишних сетевых прыжков Многие AI-sandbox решения хороши для коротких задач. Но если агент пишет приложение, ставит зависимости, меняет файлы, запускает сервер и возвращается к задаче позже, ему нужна не одноразовая среда, а нормальный компьютер. Быстрый старт:

npm install @opencomputer/sdk

или

pip install opencomputer-sdk

GitHub: github.com/diggerhq/opencomputer

«Следствие вели...» в Авито! И это не заголовок пугающей новости, а совсем наоборот ⚡️ Авито пригласил легенду тру-крайма Леонида Каневского, чтобы он разгадал таинственное и запутанное дело о внезапном росте ошибок 404 на endpoint аватарок и нашёл виновных. Звучит как план для просмотра на вечер! Кстати, кейс в основе сюжета довольно реальный... Но это уже совсем другая история 👀 📱 YouTube 📱 Rutube 📱 VK Видео

👣 Fenwick Tree на Go: всё держится на одном битовом трюке Fenwick Tree, или Binary Indexed Tree, считает prefix sums за O(log n). Главная операция:

i & -i

Она находит младший установленный бит числа. Именно это значение показывает, на сколько нужно прыгнуть по индексам внутри дерева. Пример:

i = 12        // 1100
i & -i = 4    // 0100

В Go реализация выглядит так:

package main

type Fenwick struct {
 tree []int
}

func NewFenwick(n int) *Fenwick {
 return &Fenwick{
  tree: make([]int, n+1),
 }
}

func (f *Fenwick) Update(i, delta int) {
 for i < len(f.tree) {
  f.tree[i] += delta
  i += i & -i
 }
}

func (f *Fenwick) Query(i int) int {
 sum := 0

 for i > 0 {
  sum += f.tree[i]
  i -= i & -i
 }

 return sum
}

Как это работает: * Update идёт вверх по структуре и обновляет все узлы, которые отвечают за индекс * Query идёт вниз и собирает блоки, из которых состоит prefix sum * i & -i каждый раз выбирает размер текущего блока Главный нюанс: Fenwick Tree обычно использует 1-based indexing. То есть первый элемент имеет индекс 1, а не 0. Пример использования:

fw := NewFenwick(5)

fw.Update(1, 10)
fw.Update(2, 20)
fw.Update(3, 30)

println(fw.Query(3)) // 60

Красота Fenwick Tree в том, что дерево не хранится явно. Нет указателей. Нет рекурсии. Нет сложной структуры узлов. Только массив и один битовый трюк. Дерево спрятано прямо внутри двоичного представления индексов.

LLM в поддержке: от шаблонов к точной работе с документами компании ✅ На открытом уроке разберём, как устроены современные решения на базе LLM, почему они не просто генерируют текст, а используют знания компании для подготовки ответов, и как такие инструменты помогают ускорять обработку обращений. На практических примерах покажем, как документы превращаются в базу знаний для ИИ, как происходит поиск информации по запросу клиента и каким образом LLM помогает оператору поддержки готовить ответы. Также поговорим о том, как подобные решения применяются в бизнесе уже сегодня. Урок пройдёт 6 июля в 20:00 МСК в преддверии старта курса «LLM-инженер». Это возможность познакомиться с современным подходом к созданию интеллектуальных сервисов, задать вопросы эксперту и понять, как внедрять подобные решения в реальные процессы компании. ➡️ Регистрация открыта: https://otus.pw/87OsL/?erid=2W5zFHKg1DK Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🔍 Dockpeek — минималистичный дашборд для просмотра Docker-контейнеров и их портов * Для чего Нужно быстро вспомнить, на каком хост-порту торчит сервис внутри Docker? Dockpeek показывает список контейнеров, сопоставление портов и состояние (Up, Exited) в один клик. * Ключевые особенности • Веб-интерфейс без тяжёлого JS-стека • Авторизация по логину-паролю • Чтение Docker API через socket-proxy с правами read-only • Установка одним docker compose up -d • Контейнеры кликабельны: переход по URL открывает сервис сразу на нужном порте * Быстрый старт

git clone https://github.com/dockpeek/dockpeek
cd dockpeek
cp .env.example .env    # при необходимости меняем логин/пароль
docker compose up -d

Перейдите на http://<host>:8080, войдите и увидите все порты контейнеров. * Кому пригодится – Админам, которым Portainer/Komodor кажутся избыточными – Разработчикам, у кого десятки локальных контейнеров с разными портами – Оптимизаторам CI: можно встроить в тестовый раннер как read-only просмотрщик https://github.com/dockpeek/dockpeek

Разрабатываете на Go больше четырёх лет? Сразу 7 наших команд ждут вас:

Сервис Транспорта строит маршруты во всех продуктах 2ГИС, отображает пробки, дорожные события и автобусы на карте. Social сотворяет магию вокруг социального графа. Platform Backend Services превращает бизнес‑требования в платформенные сервисы: от идеи до запуска фич мобильными командами без лишних зависимостей. Web API решает все справочные задачи, управляет стилями карт и обратной связью от пользователей в продуктах. Сервис Рекламы создаёт техническую основу для продуктов рекламного направления. 2ГИС Логистика строит и пересчитывает маршруты с учётом пробок, погодных условий, типов транспорта, параметров груза и сложных логистических цепочек. ГеоПоток помогает бизнесу повышать прозрачность процессов и сокращать издержки.

Все вакансии на сайте Другие инженерные инсайты от 2ГИС → в Telegram-канале RnD

👣 Почему один Mutex может убить производительность Go-кэша Интересный разбор для тех, кто пишет кэш в Go и думает, что проблема решается простым sync.RWMutex. Автор прогнал 6 вариантов дизайна кэша и показал неприятную вещь: один общий lock быстро становится бутылочным горлышком. Чем больше горутин лезет в кэш, тем сильнее они начинают мешать друг другу. Самый практичный вывод: шардируйте locks. Вместо одной большой map под одним mutex кэш делится на несколько shard’ов. Каждый shard хранит свою часть данных и имеет свой lock. В итоге разные goroutine чаще работают с разными locks, меньше ждут друг друга и лучше используют CPU. Отдельно интересно, что sync.RWMutex не всегда спасает. На смешанной нагрузке с чтением и записью его накладные расходы могут оказаться заметнее, чем кажется. А sync.Map тоже не превращается в универсальную кнопку «сделать быстро». Хороший материал про то, почему производительность в Go часто ломается не на алгоритме, а на конкуренции за одну общую точку. Статья: «Shard your locks: benchmarking 6 Go cache designs» https://strebkov.dev/posts/shard-your-locks/

⚡️ Solod v0.1 — системный язык с почти Go-синтаксисом, который транспилируется в C и компилируется через GCC или Clang в нативный бинарник. Он позволяет писать почти как на Go, но получать низкоуровневый контроль без Go runtime, GC и Cgo-оверхеда. В v0.1 уже портировали часть стандартной библиотеки Go: io, bufio, fmt, bytes, strings, strconv, slices, maps, os, flag, time, log/slog, crypto/rand, math/rand и другие. Отдельно добавлены пакеты mem и c: первый отвечает за явное управление памятью через аллокаторы, второй упрощает интероп с C. Например, C-библиотеки можно подключать напрямую через so:include, а функции без тела Solod сам воспринимает как extern`-декларации. Go-строки при вызове C API автоматически превращаются в `const char*, без ручного бойлерплейта. Память управляется явно, примерно в духе Zig: можно использовать системный аллокатор или арену на стеке. GC-пауз нет, но за это приходится платить ручным освобождением ресурсов. Solod пока выглядит не как замена Go, а как интересный инструмент для CLI, системных утилит, embedded-сценариев и прямой работы с C-библиотеками без Cgo. go install solod.dev/cmd/so@latest https://github.com/solod-dev/solod

Ozon Tech запускает Route 256 Pro для опытных Go-разработчиков. Это бесплатный 2-месячный интенсив на реальных проектах для тех, кто готов усилить свои навыки разработки. В программе — высоконагруженные сервисы на Go, стек и инструменты разработки Ozon Tech, проектирование и управление микросервисными системами. Участие в Route 256 Pro — это шанс прокачать сразу всё: от написания кода до архитектурного мышления в масштабах бигтеха. Это сильный нетворк с контактами в закрытом комьюнити экспертов, к которым прислушивается индустрия. Это достойное портфолио с мощным проектом в известном продукте. Если интересно узнать, как всё устроено в маркетплейсе, которыми пользуются миллионы людей, подавайте заявку: https://route256.ozon.ru/go

У триллионеров свои развлееничя: Маск покупает Cursor. По данным Reuters, сделка оценивается в $60 млрд и пройдет в формате обмена акциями. Закрытие ожидается в третьем квартале 2026 года. Контекст тут особенно интересный. Еще год назад Cursor оценивали примерно в $2,5 млрд. Стартапом также интересовались Microsoft и OpenAI, но команда хотела оставаться независимой. В итоге пришел Маск и, похоже, сделал предложение, от которого сложно отказаться. У Anthropic есть Claude Code, у OpenAI есть Codex, а теперь у экосистемы Маска может появиться Cursor как готовый enterprise-продукт для разработчиков.

restic - кроссплатформенный инструмент для бэкапов, который сохраняет зашифрованные снапшоты в 12 разных типах хранилищ. * Поддерживает Linux, macOS, Windows, FreeBSD и OpenBSD * Среди бэкендов: локальное хранилище, SFTP, S3, B2, Azure и GCS * Использует дедупликацию и шифрование для эффективных и безопасных резервных копий * Позволяет восстанавливать данные напрямую или через FUSE-mount https://github.com/restic/restic

🔍 SenPai Scanner: Найдите рабочие IP через Cloudflare SenPai Scanner — это инструмент с терминальным интерфейсом для поиска рабочих IP-адресов Cloudflare. Просто вставьте конфигурацию VLESS или Trojan и настройте параметры для проверки IP-адресов, которые действительно работают через ваш прокси. 🚀 Основные моменты: - Легкий в использовании интерфейс без командной строки - Два этапа проверки: сканирование и валидация - Поддержка нескольких платформ: Linux, macOS, Windows - Результаты сохраняются в текстовом файле для удобства 📌 GitHub: https://github.com/MatinSenPai/SenPaiScanner #go

👣 Gortex - локальный code graph и intelligence engine для AI coding agents. Агенту не нужно читать весь файл на 500 строк, если ему нужен один символ, цепочка вызовов или blast radius конкретного изменения. Gortex индексирует репозитории и отдаёт агенту только нужный кусок контекста. За счёт этого в README заявляют до 50x меньше токенов на ответ. Что умеет: - 257 языков - multi-repo workspaces - доступ через CLI, MCP Server и HTTP API - локальный запуск без внешней БД, сети и скачивания модели - symbol lookup, call chains, dataflow, clone detection, refactoring, code actions - semantic search через hybrid BM25 + vector + RRF - поддержка Claude Code, Cursor, Windsurf, Copilot, Codex CLI, Gemini CLI, Aider и других агентов Gortex умеет строить граф не только внутри одного проекта, но и между репозиториями: HTTP routes, gRPC, GraphQL, Kafka/RabbitMQ/NATS, env vars, OpenAPI и другие контракты. Это уже ближе к нормальному «пониманию системы», а не просто поиску по файлам. Gortex написан на Go, работает локально и подключается к агентам через MCP. GitHub: https://github.com/zzet/gortex #golang