Библиотека Go разработчика | Golang

📎 Cтоимость сборщика мусора Сборщик мусора в Go потребляет два ресурса: память и CPU. Чтобы понять, как им управлять, разберём простую модель. Память GC нужно помнить две вещи: что осталось живым после прошлого цикла и что выделила программа с тех пор. Сложите эти два числа и получите размер кучи…

📎 Cтоимость сборщика мусора Сборщик мусора в Go потребляет два ресурса: память и CPU. Чтобы понять, как им управлять, разберём простую модель. Память GC нужно помнить две вещи: что осталось живым после прошлого цикла и что выделила программа с тех пор. Сложите эти два числа и получите размер кучи на момент следующего запуска GC. CPU Основная работа GC состоит в том, чтобы пройтись по всей живой памяти и пометить, что ещё нужно, а что можно выбросить. Чем больше живой памяти, тем дольше это занимает. Чем больше указателей и связанных списков, тем медленнее обход. Компромисс на пальцах Представьте уборщика в офисе. Убирается каждый час — мусора почти нет, но он постоянно мешает работать. Убирается раз в день — мусор накапливается, зато никто не отвлекается. GC работает так же. Допустим, программа постоянно выделяет 10 МБ/с, а живая куча занимает 10 МБ. GC запускается каждую секунду: успевает накопиться ещё 10 МБ, куча вырастает до 20 МБ, CPU-нагрузка составляет 10%. GC запускается каждые 2 секунды: успевает накопиться 20 МБ, куча вырастает до 30 МБ, CPU-нагрузка падает до 5%. Реже запускаем — меньше грузим CPU, но тратим больше памяти. Чаще запускаем — экономим память, но платим процессорным временем. Это и есть главный компромисс GC: память vs CPU. В Go частота запуска GC является единственным параметром, которым разработчик управляет напрямую. Всё остальное GC решает сам.

❗️ Kafka выстрелила в прод в 7 утра в январские праздники Это не гипотетический сценарий, а реальный случай. Консьюмер запустился на три минуты позже, чем нужно, и этого хватило, чтобы брокер удалил все сообщения. Проводки не прошли, данные пропали. Архитектор собрал 5 типичных ошибок при работе с…

❗️ Kafka выстрелила в прод в 7 утра в январские праздники Это не гипотетический сценарий, а реальный случай. Консьюмер запустился на три минуты позже, чем нужно, и этого хватило, чтобы брокер удалил все сообщения. Проводки не прошли, данные пропали. Архитектор собрал 5 типичных ошибок при работе с Kafka, тех, что не проявляются сразу, а в самый неподходящий момент. ➡️ Читать статью

🛠 Go Fiber v3: как мигрировать с v2 Fiber v3 вышел в стабильный релиз. Если вы используете v2 в продакшене, вот что нужно знать перед миграцией и зачем она вообще нужна. Что поменялось Три изменения, которые влияют на код 1️⃣ fiber.Ctx теперь реализует context.Context В v2 приходилось вызывать …

🛠 Go Fiber v3: как мигрировать с v2 Fiber v3 вышел в стабильный релиз. Если вы используете v2 в продакшене, вот что нужно знать перед миграцией и зачем она вообще нужна. Что поменялось Три изменения, которые влияют на код 1️⃣ fiber.Ctx теперь реализует context.Context В v2 приходилось вызывать c.UserContext(), чтобы передать контекст в стандартные библиотеки. В v3 fiber.Ctx удовлетворяет интерфейсу context.Context напрямую. // v2 ctx := c.UserContext() rows, err := db.QueryContext(ctx, "SELECT ...") // v3 rows, err := db.QueryContext(c, "SELECT ...") 2️⃣ Статика переехала в middleware Метод app.Static() убран. Его функциональность перенесена в отдельный static middleware. // v2 app.Static("/", "./public") // v3 import "github.com/gofiber/fiber/v3/middleware/static" app.Use("/", static.New("./public")) 3️⃣ Изменился метод Listen Метод Listen объединён с конфигурацией. Настройки теперь передаются напрямую в вызов. Если у вас есть кастомная конфигурация запуска сервера, придётся поправить. Как мигрировать Команда Fiber выпустила CLI с встроенным инструментом миграции: go install github.com/gofiber/cli/fiber@latest fiber migrate --to v3 После запуска обязательно проверяйте весь diff вручную. Инструмент иногда меняет код, который к Fiber не относится. Что ещё появилось в v3 Drop() — тихий сброс соединения без ответа клиенту, удобно для DDoS-защиты. End() — немедленный сброс ответа. SendEarlyHints() — поддержка HTTP 103. Пакет extractors с единым API для извлечения значений из заголовков, кук, query-параметров и форм. Раньше каждый middleware дублировал эту логику по-своему. RouteChain для Express-стиля объявления маршрутов. HEAD-маршруты теперь регистрируются автоматически для каждого GET. Нативная поддержка context.Context убирает целый класс бойлерплейта. Основные breaking changes — это статика и конфигурация Listen, они чинятся быстро. Запустите CLI-инструмент, прогоните тесты, вручную проверьте diff.

👨‍💻 Markdown-CMS на Go без базы данных Markdown-CMS — это система управления контентом, где вместо базы данных и визуального редактора используются обычные .md файлы с текстом. Foundry это свежий проект как раз про такой подход. Пайплайн простой: конфиг → загрузка контента → граф сайта → маршрут…

👨‍💻 Markdown-CMS на Go без базы данных Markdown-CMS — это система управления контентом, где вместо базы данных и визуального редактора используются обычные .md файлы с текстом. Foundry это свежий проект как раз про такой подход. Пайплайн простой: конфиг → загрузка контента → граф сайта → маршруты → рендеринг → public/. Два графа в памяти: SiteGraph: документы, роуты, таксономии; и DependencyGraph для инкрементальных пересборок. При изменении файла пересобираются только затронутые страницы. Что есть из коробки Плагины с хуками на загрузку/сборку/раздачу, темы с layout-слотами, RSS и sitemap, импорт из WordPress и legacy-Markdown, JS SDK для фронтенда и админки. Валидация битых ссылок, осиротевших медиафайлов и дублирующихся URL — командой foundry validate. Быстрый старт: go install github.com/sphireinc/foundry/cmd/foundry@latest foundry serve # dev-сервер с live reload foundry build # статика в public/ ➡️ Репозиторий

📎 Анализатор и инъекции 802.11 на Go Gapcast — это инструмент для аудита WiFi-сетей: перехват пакетов, инъекции, Evil Twin с Captive Portal и оценка дистанции до точки доступа по RSSI. Написан на Go, лицензия GPL-2.0. Что умеет Сканирование 2.4 и 5 ГГц одновременно, запись в .pcap, восстановление…

📎 Анализатор и инъекции 802.11 на Go Gapcast — это инструмент для аудита WiFi-сетей: перехват пакетов, инъекции, Evil Twin с Captive Portal и оценка дистанции до точки доступа по RSSI. Написан на Go, лицензия GPL-2.0. Что умеет Сканирование 2.4 и 5 ГГц одновременно, запись в .pcap, восстановление данных из файла — в том числе от Wireshark. Deep Scan по одному BSSID проходит три фазы: определение канала, сбор пакетов, расчёт дистанции. Установка git clone https://github.com/ANDRVV/gapcast.git cd gapcast && go build -buildvcs=false ./gapcast -i <interface> Сканирование сетей: # 2.4 ГГц ./gapcast -i wlan0 # 5 ГГц ./gapcast -i wlan0 -5g # Оба диапазона + радар дистанции ./gapcast -i wlan0 -2.4+5g -radar # Только точки доступа, без клиентов ./gapcast -i wlan0 -2.4+5g -beacon # Долгое сканирование без пропуска неактивных устройств ./gapcast -i wlan0 -2.4+5g -d ➡️ Репозиторий

⭐️ Проверка интерфейсов на этапе компиляции В Go тип реализует интерфейс неявно, никаких implements не нужно. Это элегантно, но создаёт тихую ловушку: вы думаете, что тип реализует интерфейс, но из-за несовпадения сигнатуры метода — не реализует. Узнаёте об этом только в рантайме, когда присвоение …

⭐️ Проверка интерфейсов на этапе компиляции В Go тип реализует интерфейс неявно, никаких implements не нужно. Это элегантно, но создаёт тихую ловушку: вы думаете, что тип реализует интерфейс, но из-за несовпадения сигнатуры метода — не реализует. Узнаёте об этом только в рантайме, когда присвоение падает. Лечится одной строкой, которая ничего не стоит в рантайме: var _ io.Reader = (*MyReader)(nil) Что здесь происходит Объявляется переменная типа io.Reader, ей присваивается nil-указатель на MyReader, результат выбрасывается. Если *MyReader не реализует интерфейс, то компилятор отклонит код. Если реализует, то строка компилируется и не генерирует никакого кода. Такой же приём используется в стандартной библиотеке Go и в крупных open-source проектах.

✏️ Уязвимость в Gogs при удалении релизов При удалении релиза Gogs вызывает git-команду примерно так: process.ExecDir(..., "git", "tag", "-d", rel.TagName) rel.TagName передаётся напрямую, без разделителя --. Если имя тега начинается с -, Git воспринимает его как флаг, а не как аргумент. Это класс…

✏️ Уязвимость в Gogs при удалении релизов При удалении релиза Gogs вызывает git-команду примерно так: process.ExecDir(..., "git", "tag", "-d", rel.TagName) rel.TagName передаётся напрямую, без разделителя --. Если имя тега начинается с -, Git воспринимает его как флаг, а не как аргумент. Это классическая инъекция аргументов. Что делать Обновиться до Gogs 0.14.2. Уязвимость обнаружили и закрыли. ➡️ Источник

🛠 Конкурентность без бойлерплейта Когда нужно запустить несколько горутин, дождаться всех и обработать первую ошибку, то руки обычно тянутся к sync.WaitGroup плюс канал для ошибок. Это легко сделать неправильно: пропустить ошибку, получить дедлок, написать двадцать строк там, где достаточно пяти. …

🛠 Конкурентность без бойлерплейта Когда нужно запустить несколько горутин, дождаться всех и обработать первую ошибку, то руки обычно тянутся к sync.WaitGroup плюс канал для ошибок. Это легко сделать неправильно: пропустить ошибку, получить дедлок, написать двадцать строк там, где достаточно пяти. Давайте попробуем использовать errgroup. g.Go запускает горутину. g.Wait ждёт все и возвращает первую ненулевую ошибку. Если любая горутина вернула ошибку — производный ctx отменяется, остальные горутины, которые слушают контекст, завершаются досрочно: func fetchAll(ctx context.Context, ids []string) ([]Result, error) { g, ctx := errgroup.WithContext(ctx) results := make([]Result, len(ids)) for i, id := range ids { i, id := i, id // захватываем переменные цикла g.Go(func() error { r, err := fetch(ctx, id) if err != nil { return err } results[i] = r return nil }) } if err := g.Wait(); err != nil { return nil, err } return results, nil } Если нужно сделать 200 запросов, но не более 10 одновременно — errgroup хорошо компонуется с семафором: sem := semaphore.NewWeighted(10) g.Go(func() error { if err := sem.Acquire(ctx, 1); err != nil { return err } defer sem.Release(1) return doWork(ctx) }) С sync.WaitGroup и каналом вам нужно самостоятельно: не забыть wg.Add, не забыть wg.Done в defer, правильно буферизировать канал ошибок, не заблокироваться на записи в него, вручную отменять контекст при ошибке. errgroup делает всё это за вас и при этом хорошо компонуется с таймаутами и отменой.

👨‍💻 Вызов Go-функции из JIT-кода Go не создан для JIT-компиляции. Сборщик мусора требует строгой формы стека, и если JIT-код нарушает эти ожидания, программа падает с fatal error: unexpected signal during runtime execution. Разработчик решил эту проблему и опубликовал библиотеку gojit. Почему это…

👨‍💻 Вызов Go-функции из JIT-кода Go не создан для JIT-компиляции. Сборщик мусора требует строгой формы стека, и если JIT-код нарушает эти ожидания, программа падает с fatal error: unexpected signal during runtime execution. Разработчик решил эту проблему и опубликовал библиотеку gojit. Почему это сложно В Go два ABI. ABI0 передаёт аргументы через стек, ABIInternal через регистры. Внутри рантайма Go использует ABIInternal, снаружи видит ABI0. JIT-код об этом ничего не знает. Добавьте сюда сборщик мусора, который в любой момент может проверить стек, и прямой вызов Go-функций из JIT превращается в лотерею. Как это решает gojit Трюк в том, чтобы вызывать Go-функцию не напрямую из JIT-кода, а через метку внутри Go Assembly. Рантайм Go считает такой вызов легитимным и не падает при сборке мусора или росте стека. В ассемблерный трамплин добавляется метка gocall: TEXT ·callJIT(SB), 0, $8-8 NO_LOCAL_POINTERS MOVQ code+0(FP), AX JMP AX gocall: CALL CX JMP (SP) Отдельная asm-функция возвращает точный адрес ABI0-реализации, а не адрес ABIInternal-обёртки, которую Go подставляет по умолчанию. Зная этот адрес, JIT-код кладёт указатель на Go-функцию в RCX, прыгает в gocall, функция выполняется, стек возвращается в порядок. В библиотеке всё это спрятано за методом CallFunc(f func). ➡️ Репозиторий | Источник

⚙️ sync.Pool это не кэш sync.Pool это один из самых неправильно понимаемых типов в стандартной библиотеке. Выглядит как пул объектов, им и является, но с одной гарантией, которая удивляет: GC может выселить всё содержимое пула в любой момент, без предупреждения. Для чего он реально нужен Один кон…

⚙️ sync.Pool это не кэш sync.Pool это один из самых неправильно понимаемых типов в стандартной библиотеке. Выглядит как пул объектов, им и является, но с одной гарантией, которая удивляет: GC может выселить всё содержимое пула в любой момент, без предупреждения. Для чего он реально нужен Один конкретный сценарий: снизить давление аллокаций для короткоживущих переиспользуемых объектов: bytes.Buffer, структуры протокольных сообщений, временные срезы. var bufPool = sync.Pool{ New: func() any { return new(bytes.Buffer) }, } func processRequest(data []byte) []byte { buf := bufPool.Get().(*bytes.Buffer) buf.Reset() // обязательно: сбрасываем перед использованием defer bufPool.Put(buf) buf.Write(data) return buf.Bytes() } Две ошибки, которые случаются почти всегда Забыть Reset(). Пул переиспользует объект, но не его содержимое. Всё, что записал предыдущий пользователь, никуда не делось. Всегда сбрасывайте состояние перед работой с полученным объектом. Использовать объект после Put. Как только вызвали Put — объект принадлежит пулу. Обращение к buf.Bytes() после возврата — это гонка данных, которая просто ещё не выстрелила.