Дженерики в Go: чем платит архитектура за type parameters

С Go 1.18 (март 2022) в язык добавили параметры типов. За три года они перестали быть новинкой и превратились в архитектурный выбор: где-то interface{} с рефлексией заменили на дженерик и получили и скорость, и типобезопасность, а где-то тот же дженерик раздул бинарник, усложнил чтение сигнатур и не дал ничего, кроме удовольствия автора. Разберём, что именно меняется в структуре кода, когда вы вводите func Map[T, U any](...), и чем за это платите.

Что реально сделали дженерики в архитектуре

До 1.18 обобщённый код в Go писали тремя способами: копипаста под каждый тип, interface{} с приведением и рантайм-проверкой, кодогенерация через go generate. У каждого своя цена. Копипаста — дублирование логики. interface{} — потеря типов на границе и паника при неверном приведении. Кодогенерация — отдельный шаг сборки и артефакты в репозитории.

Параметры типов закрывают этот разрыв, но не бесплатно и не для всех случаев. Компилятор Go использует стратегию GC shape stenciling¹: он не генерирует отдельную копию функции под каждый конкретный тип, как C++ templates, но и не сводит всё к одному коду через боксинг, как Java. Он группирует типы по «форме» для сборщика мусора — все указатели делят одну инстанциацию, а типы по значению получают свои. Это компромисс, и он диктует, как ваш код будет вести себя под нагрузкой.

Почему это влияет на структуру пакетов

Дженерик-функция не может жить в вакууме. Как только вы выносите type Cache[K comparable, V any] в общий пакет, все зависящие пакеты наследуют её параметры типов в своих сигнатурах. Обобщение протекает вверх по слоям: репозиторий стал дженериком — сервис, который его вызывает, либо тоже становится дженериком, либо фиксирует конкретный тип на границе. Второе почти всегда правильнее.

Три архитектурных последствия, за которые вы платите

1. Раздувание бинарника и времени компиляции

Каждая уникальная GC shape инстанциации порождает свой машинный код. Если ваш Set[T] используется с int, int64, string и десятком собственных value-структур, компилятор выпустит отдельную копию под каждую форму по значению. Типы-указатели (*User, *Order) делят одну инстанциацию — их форма для GC одинакова.

Практический вывод для архитектуры: если вы храните в обобщённом контейнере указатели, а не значения, кода генерируется меньше. Но точную величину прироста бинарника нельзя предсказать по формуле — её надо мерить на своём проекте через go build -ldflags="-s -w" и сравнение размеров до и после. Не подставляйте сюда чужие проценты.

2. Методы не могут иметь своих параметров типов

Это ограничение спецификации, а не временное. Метод наследует параметры типа своего получателя, но не может объявить собственные:

// Go 1.18+ — так НЕ скомпилируется:
// func (c *Cache[K, V]) MapTo[U any](f func(V) U) *Cache[K, U]

// Придётся выносить в свободную функцию:
func MapCache[K comparable, V, U any](c *Cache[K, V], f func(V) U) *Cache[K, U] {
    result := NewCache[K, U]()
    for key, value := range c.items {
        result.Set(key, f(value))
    }
    return result
}

Архитектурное последствие: fluent-стиль (cache.Map(...).Filter(...)) с изменением типа элемента в Go недостижим. Вы либо строите API вокруг свободных функций (slices.Map, maps.Keys — именно так устроена стандартная библиотека), либо фиксируете тип результата. Если вы проектируете обобщённую коллекцию с богатым API, заложите это ограничение сразу, а не упритесь в него на середине.

3. Ограничения (constraints) — это контракт, который тяжело менять

Constraint вида comparable или собственный интерфейс с type set — публичная часть API. Расширить его позже безопасно, сузить — ломающее изменение для всех, кто уже вызвал функцию с типом, который перестал подходить. То же, что и с обычными интерфейсами, но заметнее: constraint часто пишут «в притык» под текущие нужды.

Дженерик стоит вводить там, где вы можете назвать минимум два разных типа, которые уже сегодня ходят через этот код. Один тип — это не обобщение, это преждевременная абстракция, которую придётся сопровождать годами.

Когда дженерик оправдан, а когда — нет

Ключевой критерий выбора между дженериком и интерфейсом: дженерик — про одинаковую логику над разными типами данных, интерфейс — про разную логику за одним контрактом. Если внутри тела функции вам приходится делать switch по конкретному типу параметра — это не задача для дженерика, это интерфейс с методом.

Где подход ломается

• Нельзя вызвать метод параметра типа, если он не в constraint. func Process[T any](v T) не даст вам вызвать v.Validate() — нужно добавить метод в constraint-интерфейс, и тогда типы без него отпадут.
• Нет частичной специализации. Вы не напишете «отдельную реализацию для string» внутри дженерика без рантайм-проверки типа — а она возвращает вас к тому interface{}, от которого уходили.
• Type inference спотыкается на возвращаемых типах. Часто приходится указывать параметры явно: Map[User, string](users, f). Это шум в вызовах, который накапливается.
• Дебаг инстанциаций. В стектрейсах и профилировщике имена инстанциированных функций выглядят как Cache[go.shape.string] — читаемо, но непривычно, и осложняет grep по коду.

Что мерить и что делать дальше

Если вы вводите дженерики в существующий сервис — не полагайтесь на ощущение «стало чище». Проверьте три показателя до и после на своём проекте:

1. Размер бинарника. Соберите с и без дженериков, сравните вывод ls -la или go tool nm. Прирост от инстанциаций может быть незаметным, а может — ощутимым, зависит от числа GC shape.
2. Время компиляции. go build дженериков дороже — замерьте time go build ./... на чистом кеше.
3. Аллокации в горячем пути. Дженерик по значению избегает боксинга, который был у interface{} — проверьте бенчмарком с -benchmem, действительно ли снизились аллокации, ради которых вы всё затевали.

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

¹ GC shape stenciling — стратегия компилятора Go: под каждую «форму» типа для сборщика мусора (все указатели — одна форма, каждый value-тип — своя) генерируется отдельная копия обобщённого кода, а внутри формы типы разделяются через словарь метаданных. Компромисс между полной мономорфизацией (как в C++) и единой боксированной реализацией.