Стоит ли расширять Go ценой его минимализма?

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

Статья на DEV Community показывает конфликт на двух уровнях. Новые конструкции решают реальные задачи, но добавляют правила, которые нужно помнить. Старые пробелы тоже усложняют код: без отдельного типа для необязательных значений разработчики используют указатели и собственные обёртки, а единообразия становится меньше.

Это концептуальная колонка, а не сравнение языков или разбор кода. Её полезно читать как повод проверить критерии развития языка: какие возможности окупают новую сложность, а какие размывают исходную модель.

Где для вас проходит эта граница в Go?