🫡 Еженедельный дайджест №1

Для тех, кто был слишком занят на неделе или просто пропустил некоторые посты, публикуем дайджест!

– Generic интерфейсы в Go: просто, но сложно
– Что нового в GoLand 2025.2?
– Как проверить время и асинхронный код в Go?
– Вышли минорные релизы Go — 1.25.1 и 1.24.7
– Оптимизация памяти в Go: 20 приёмов для эффективных приложений
– Как превратить SQL в полноценный API прямо в Go?

Самый популярный комментарий этой недели – комментарий к статье "Generic интерфейсы в Go: просто, но сложно" от пользователя @AuToMaton:

А в старое время это делалось иначе. Никто никаких паттернов не обсуждал и не придумывал, все делали по простому. А когда замечали что делают одно и то же трижды, смотрели на написанное и устраняли дублирование.

@go_for_devs

🔥 Как мы выследили регрессию использования памяти в продакшен-сервисах на Go 1.24

Команда Go for Devs подготовила перевод статьи о том, как команда инженеров выявила регрессию использования памяти в Go 1.24.

Оказалось, что всего одна оптимизация в аллокаторе памяти, случайно потерянная при рефакторинге, заставляла Go «съедать» сотни мегабайт RAM.

Но сообщество Go-разработчиков быстро нашло и устранило проблему 🫡

📚 Подробности на Хабр: https://habr.com/ru/articles/944718/

🤷 Зачем в Go интерфейсы требуют точного совпадения?

В Go компилятор иногда автоматически преобразовывает значение тика к указателю на этот тип. Если вызвать метод с pointer-receiver на значении, всё будет работать:

type User struct {
    Name string
}

func (u *User) SetName(name string) {
    u.Name = name
}

func (u User) PrintName() {
    fmt.Println(u.Name)
}

var u User
u.SetName("Alice")   // Go превратил это в (&u).SetName("Alice")
u.PrintName()        // Обычный value-receiver

Но стоит подключить интерфейсы — и магия исчезает:

type Named interface {
    SetName(string)
    PrintName()
}

var u User
var n Named

n = &u // OK: *User реализует оба метода
n = u  // Ошибка: User не имеет SetName

Почему так?

У User (значения) в method set только методы с value-receiver. У *User — и value-, и pointer-receiver. Автоматическое «взятие адреса» при работе с интерфейсами запрещено, потому что интерфейс хранит копию значения, а не сам объект.

Копия:
* неадресуемая,
* неизменяемая.

Если бы мы могли взять &n.(User), получили бы указатель на временную копию внутри интерфейса, которая теряется при новом присваивании. Это небезопасно.

Итог

* Интерфейсы всегда копируют значение.
* Копия не имеет адреса и не может изменяться.
* Поэтому Go не делает auto-addressing, и method set интерфейса и method set конкретного значения должны строго совпадать.

🙏 Git bisect: быстрый способ найти баг

Вы когда-нибудь ловили баг в проекте, который «ещё вчера работал»?

Коммитов — целая гора, глазами не найти. Тут и выручает git bisect.

Это штука, которая делает бинарный поиск по истории. Вы указываете, где баг точно есть (git bisect bad HEAD), и где его точно не было (git bisect good abc123).

Дальше Git сам переключает вас на середину между "плохим" и "хорошим" кодом и говорит: «проверь».

Вы смотрите: баг есть → git bisect bad, бага нет → git bisect good.

И так несколько раз, пока Git не ткнёт пальцем в конкретный коммит: вот тут всё сломалось.

Фишка в том, что даже если между good и bad 100 коммитов, руками проверять придётся не сто, а всего 6–7. Логарифмы в действии 🙂

А если повезло, и баг можно проверить скриптом (например, тест падает с кодом 1) — вообще красота:

git bisect run ./test_bug.sh

Git сам пройдётся по истории и принесёт виновника на блюдечке.

Так что если в следующий раз придётся охотиться за багом — не спешите листать git log. Пусть git bisect сделает грязную работу 😉

🔧 Целостность данных JSON-колонок в PostgreSQL

JSON всё чаще используют в реляционных базах данных — он позволяет хранить гибкие структуры и избавляет от избыточных связей между таблицами. Но вместе с удобством появляется риск: данные могут потерять предсказуемость.

Если не контролировать содержимое JSON-колонок, туда легко попадут неожиданные значения: числа вместо строк, объекты вместо массивов. В итоге приложение может «сломаться» на ровном месте.

В MySQL проверка JSON поддерживается из коробки. В PostgreSQL для этого есть расширение, которое позволяет валидировать данные по JSON-схеме прямо на уровне БД.

Пример: у нас есть таблица products с колонкой attributes, где хранятся характеристики товара.

CREATE TABLE products (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  price DECIMAL(10, 2) NOT NULL,
  attributes JSON NOT NULL DEFAULT '{}'
);

Мы ожидаем, что поле tags внутри этого JSON будет массивом строк. Однако без строгой проверки на уровне базы данных нет гарантии, что кто-то не запишет туда числа, объекты или вообще что-то неподходящее.

Чтобы сохранить гибкость JSON и одновременно обеспечить строгую структуру данных, можно использовать валидацию JSON-схемы на уровне базы данных. Для этого нужно добавить constraint, который автоматически проверит соответствие содержимого JSON определенной схеме при каждой операции вставки или обновления.

Пример для PostgreSQL:

ALTER TABLE products ADD CONSTRAINT data_is_valid CHECK(
  validate_json_schema(
    '{
      "type": "object",
      "properties": {
        "tags": {
          "type": "array",
          "items": { "type": "string" }
        }
      },
      "additionalProperties": false
    }',
    attributes
  )
);

Теперь, попытка вставить данные с невалидным значение для tags приведёт к ошибке:

INSERT INTO products (..., attributes) VALUES 
(..., '{}'),                 -- Пустой объект, допускается
(..., '{"tags": []}'),       -- Пустой массив строк
(..., '{"tags": ["test"]}'); -- Массив со строкой
-- Результат: Операция успешна

INSERT INTO products (..., attributes) VALUES 
(..., '{"tags": [2]}');      -- Массив с числом вместо строки
-- Ошибка: Нарушен constraint

🪲 За пределами отладчика: полное руководство по отладке Go-приложений

В новой статье рассказываем о том, что баги бывают разными: воспроизводимые, случайные, гейзенбаги и конкурентные.

А в арсенале Go-разработчика должны быть — TDD, стратегическое логирование, Delve, git bisect и даже онлайн-отладчик GoTutor.

📚 Подробности на Хабр: https://habr.com/ru/articles/944732/

#GoHero ⭐️ Rob Pike

Команда Go for Devs считает важным рассказать о людях, которые внесли наибольший вклад в развитие языка Go и его экосистемы. В первом посте из серии #GoHero мы расскажем о Робе Пайке — человеке, чье имя давно стало легендой в мире компьютерных наук.

–––

Rob Pike — один из трёх создателей Go, наряду с Ken Thompson и Robert Griesemer. До этого он уже оставил яркий след в истории: участвовал в разработке Unix, Plan 9 и Inferno, а также был соавтором кодировки UTF-8.

Первые работы над Go начались в 2007 году внутри Google, а официально язык был представлен в ноябре 2009 года.

Pike сыграл ключевую роль в формировании философии Go: простота, читаемость и скорость разработки превыше всего.

Помимо инженерных достижений, Rob Pike известен и как автор книг: вместе с Brian Kernighan он написал «The Unix Programming Environment» и «The Practice of Programming».

Сегодня Rob Pike продолжает работать в Google, оставаясь важной фигурой в команде Go. Его влияние чувствуется не только в языке, но и в самой культуре разработки — от подхода к простоте кода до принципов открытого сообщества.

🫡 Еженедельный дайджест №2

Для тех, кто был слишком занят на неделе или просто пропустил некоторые посты, публикуем дайджест!

Статьи:
– Как мы выследили регрессию использования памяти в продакшен-сервисах на Go 1.24
– Топ 5 возможностей Gin, которые должен знать каждый Go-разработчик
– Новый экспериментальный API для JSON в Go
– За пределами отладчика: полное руководство по отладке Go-приложений
– Genkit Go 1.0: AI-фреймворк для продакшена

Посты-коротыши:
– Зачем в Go интерфейсы требуют точного совпадения?
– Git bisect: быстрый способ найти баг
– Целостность данных JSON-колонок в PostgreSQL
– GoHero ⭐️ Rob Pike

Опросы:
– Используете ИИ-ассистентов для написания production-кода?

Самый популярный комментарий этой недели – комментарий к статье "Топ 5 возможностей Gin, которые должен знать каждый Go-разработчик" от пользователя @starwalkn:

При создании веб-API на Go, фреймворк Gin часто становится первым
Да, особенно в галерах, где важнее быстро наклепать продукт и забыть о нем. А в реальности же из-за несовместимости Gin со стандартным net/http (привет, Chi!) весь API будет зависеть именно от него и при смене роутера придется переписывать абсолютно все хэндлеры.

Пункт 1. Причем тут вообще Gin? Сервер создается и настраивается из пакета net/http и конфигурируется как душе угодно, Gin тут идет всего лишь как роутер, будь то горилла или http.ServeMux

Пункт 2. Обычный паттерн любого роутера, в чем тут особенность Gin?

Пункт 4. Опять же, каким боком тут Gin и его особенности? Вы останавливаете сервер, а не роутер

Ощущение, что автор статьи не работал ни с чем, кроме Gin и выдает его за волшебный способ реализации API, к тому же не различает понятия сервера и роутера. И где же тут "скрытые фишки"?

@go_for_devs

🔥 PostgreSQL 18: Виртуальные колонки — меньше кода, больше гибкости

PostgreSQL 18 принёс асинхронный I/O, UUID v7 и ещё кучу полезного. Но фича, которая нас реально радует — виртуальные вычисляемые колонки. Это способ держать бизнес-логику ближе к данным и не плодить триггеры и boilerplate-SQL.

Как было раньше: надо было дублировать одни и те же выражения в запросах, вьюхах, функциях. Забыл обновить — привет баги. С виртуальными колонками логика всегда в одном месте, и данные остаются консистентными.

Пример:

create table users (
  id serial primary key,
  name text not null,
  -- stored: пишется на диск, индексируется
  name_upper text
    generated always as (upper(name)) stored,
  -- virtual: считается на лету
  name_lower text
    generated always as (lower(name)) virtual
);

name_upper отлично индексировать, name_lower — не занимает места и моментально добавляется даже в огромную таблицу.

А вот более практичный сценарий — полнотекстовый поиск на нескольких языках:

create table docs (
    id serial primary key,
    body text not null,
    body_fts_simple tsvector
        generated always as (to_tsvector('simple', body)) stored,
    body_fts_en tsvector
        generated always as (to_tsvector('english', body)) stored,
    body_fts_el tsvector
        generated always as (to_tsvector('greek', body)) stored
);

create index on docs using gin (body_fts_simple);
create index on docs using gin (body_fts_en);
create index on docs using gin (body_fts_el);

Теперь поиск по разным языкам не требует триггеров и всегда синхронизирован с данными.

Итого:

* virtual — для лёгких выражений, быстрых экспериментов и JSON-поля без дублирования.
* stored — для тяжёлых вычислений, которые нужны в индексах.

#postgres@go_for_devs

🛠 Разработка RESTful API на Go и Gin

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

Отличный старт для знакомства с Gin!

📚 Подробности на Хабр: https://habr.com/ru/articles/947528/