Comments 13
Статья интересная, но три последних абзаца видимо случайно продублированы.
К оригинальной статье есть неплохое дополнение: https://www.dolthub.com/blog/2022-04-01-fast-generics
встраивать код в строку
Оригинальный перевод, даже "google translate" достаточно
умен чтобы "inline code" не переводить как "встраивание в строку".
r/programmingcirclejerk в восторге
Почитав раздел о рисках в оригинальном предложении по полной мономорфизации в Go 1.18, представляется, что решение реализовать дженерики с применением словарей было принято потому, что мономорфизировать код медленно
несколько раз задавался вопросом почему у golang нет «медленного режима». меня устраивает сборка релиза большого проекта часами, если в результате мы получим выигрыш и по быстродействию, и по размеру бинарника на десятки процентов.
единственное серьёзное возражение, которое приходит в голову: это будет очень другой бинарник, в релизной сборке могут вылезти проблемы, которых не было в девелоперской.
Потому что нужно оба эти режима в компиляторе реализовать, а это человекочасы. И возможно для дженериков сделают какой-нибудь флаг потом который включит реальный шаблонизатор, а не этот странный гибрид... надеюсь. В остальном там, по моему, компромисов особо нет.
И это абсолютно правильное возражение. Это часть идеологи языка, написал, сбилдил, запустил с минимальными телодвижениями. Рано или поздно флагов становится сильно много, можно что то опустит, а где то начинаются игры с флагами и разработчик тратит время не на разработку(фикс n^3 алгоритма), а флажки подбирает чтобы оно хоть как то работало.
Видел где то что разработчик голанга на вопрос про флаги ответчал что если оптимизация рациональная, то она будет включена в язык, а не добавлена как флаг.
Но соглашусь что выстрелил они себе в ногу с таким алгоритмом для дженериков, что теперь из каждого чайника вещают что они медленнные
Что за редактор такой в статье, который справа сразу отображает ассемблеровский код?
Дженерики могут замедлить ваш код на Go