Когда дженерики, когда интерфейсы: решение, которое реально принимает senior-ревьюер

Два разных вопроса: поведение или данные?

Интерфейсы и дженерики оба абстрагируют, но отвечают на разные вопросы. Интерфейс отвечает, что это значение умеет делать — он стирает конкретный тип за множеством методов, решение принимается в рантайме; поэтому один []io.Reader может одновременно держать файл, буфер и сетевое соединение. Параметр типа отвечает, над каким типом работает этот код — он сохраняет конкретный тип через всё вычисление, решение принимается при компиляции; поэтому Min[T cmp.Ordered] может вернуть тот же тип, что получил, а не any, который вызывающему придётся assert-ить. Из этих двух фактов вытекает рабочее правило, прямо от авторов языка: если тело функции только вызывает методы значения — берите интерфейс. Тянитесь к параметрам типов, когда строите структуры данных или когда функции должны работать со слайсами, мапами и каналами любого типа элементов. Сигнатура часто выдаёт ответ: func Log[T fmt.Stringer](v T) использует T ровно один раз — параметр типа не сохраняет ничего наблюдаемого; func Dedup[T comparable](xs []T) []T требует, чтобы тип протёк от входа к выходу, чего интерфейс не выразит, не заставив вызывающего делать assertions.

// Поведение: тело только вызывает методы — правильный инструмент интерфейс.
func Log(v fmt.Stringer) { logger.Print(v.String()) }

// Данные: тип элемента должен дожить от аргумента до результата.
func Dedup[T comparable](xs []T) []T {
	seen := make(map[T]struct{}, len(xs))
	out := xs[:0:0]
	for _, x := range xs {
		if _, ok := seen[x]; !ok {
			seen[x] = struct{}{}
			out = append(out, x)
		}
	}
	return out
}

Канон: чему учат slices, maps и cmp

Собственные дженерики стандартной библиотеки — slices, maps, cmp (Go 1.21) — это калибровочный набор для вкуса. Посмотрите, что у них общего: каждая функция — алгоритм над типом элементов контейнера. slices.Contains, slices.SortFunc, maps.Keys, cmp.Ordered — ни одна не моделирует поведение; всем до 1.18 были нужны interface{} и рефлексия (или копипаста по типам). И посмотрите, как поведение входит туда, где алгоритму оно нужно: slices.SortFunc(s, func(a, b T) int) принимает функциональное значение, а не constraint с методами. Передача поведения явной func держит constraint минимальным (any) и позволяет вызывающим сортировать по чему угодно, не объявляя тип. Вот канон в двух правилах: дженерики владеют контейнером и типом элементов; поведение приходит аргументом-функцией или остаётся за интерфейсом. Поймали себя на constraint с множеством методов — [T interface{ Validate() error }] — остановитесь и проверьте, не скажет ли это лучше func(t T) error или обычный интерфейсный параметр.

Антипаттерны, которые ревьюер должен называть вслух

Дженерики везде. Функция с единственным конкретным использованием получает параметр типа «на будущее». Цена сегодня: тяжелее сигнатура, медленнее сборка, бухгалтерия инстанцирований; выгода: ноль, пока это будущее не наступит — а тогда добавить параметр было бы механической правкой. Пишите конкретную версию первой; обобщайте на втором настоящем вызывающем.

Constraints из одних методов в позиции аргумента. func Render[T fmt.Stringer](v T) — дженерик-запись интерфейсного параметра. У неё есть одна честная ниша: когда вызывающие передают типы-значения и вызов горячий, инстанцирование может убрать аллокацию интерфейсного боксинга и девиртуализовать. Ниша реальна, но узка — сначала измерьте: для аргументов-указателей gcshape-словарь даёт тот же косвенный вызов, что и интерфейс.

Расползание constraints. Самописные пакеты constraints, дублирующие cmp.Ordered; трёхстрочные constraints, экспортированные из пяти пакетов; объединения, перечисляющие типы, которым следовало быть интерфейсом. Constraints — это API; каждый экспортированный — вещь, которую пользователи должны понять, а вы — держать стабильной.

Параметры типов, которые вызывающим приходится писать всегда. Если каждая точка вызова читается как Parse[Config](data), потому что выводу не на что смотреть, подумайте, не хочет ли дизайн обычного аргумента (Parse(data, &cfg)) — он и с существующим кодом компонуется лучше.

У всех этих антипаттернов общий корень: дженерик-форма была выбрана потому, что синтаксис позволял, а не потому, что типу нужно было протечь насквозь. Без второго настоящего вызывающего — того, ради которого обобщение окупится, — вы несёте все издержки и не получаете никакой выгоды.

Производительность, честно

Перфоманс-аргумент за дженерики регулярно перегибают в обе стороны, поэтому вот механика. Для инстанцирований с типами-значениями компилятор генерирует выделенный код: сравнения и вызовы прямые, инлайнируемые, и выигрыш над версией с interface{} реален — нет боксинг-аллокаций, нет динамической диспетчеризации в горячем цикле. Пересобранная так сортировочная машинерия (slices.Sort против sort.Sort на []int) попадает в диапазон «десятки процентов — разы», поэтому контейнеры и алгоритмы и есть каноническое применение. Для инстанцирований с указателями все аргументы делят один gcshape: вызовы на параметре типа идут через словарь — косвенно, без инлайнинга — что примерно интерфейсный вызов под другим именем. Поэтому спринт из Hook и намерил ровные графики: перевод параметров io.Reader в [R io.Reader] перенёс косвенность из интерфейсной таблицы в словарь, не убрав её. И издержки несимметричны: каждый отдельный шейп-значение добавляет машинный код (размер бинарника, кеш инструкций, время сборки) — это и есть те 12%, что поймал пайплайн. Честное резюме для комментария в ревью: дженерики выигрывают там, где типы-значения встречают алгоритмы; играют вничью или слегка проигрывают там, где указатели встречают поведение; и всегда стоят времени компиляции и байтов.