Понял, спасибо.
Именно после чтения исходников вопрос и назрел, хотя я начал подозревать неладное еще когда увидел "func", типа серьезно, экономия нескольких букв в эпоху IDE?
Я думаю, что буду систематически их нарушать в пользу 3-х буквенных переменных и ограничения в несколько самых популярных однобуквенных на одну функцию.

+ линтер настрою на ограничение в 20 строк кода а одну функцию.

Уровень- скилл

Тут скорее не в IDE вопрос, а в том, что Пайк и Ко. решили не останавливаться на отсутствии тернарного оператора и дженериков, а пошли ещё дальше: заменили страшные veryLongVariables на красивые и лаконичные "v, b, n" etc. А вот err != nil на каждом чихе их почему-то не смутило.

Это плохо? Прувы !

Это была многоходовочка, чтобы в этом году грандизоно ввести дженерики.
Больше всего меня радует v // value - это реально нужно было еще постараться, чтобы к этому придти.

Ну, ошибки в Go на самом деле интересно решили обрабатывать, если думать об этом исключительно в рамках идиоматического кода и желательно микросервисов в облаках.
Я посмотрел несколько конференция и понял это так:
а) Ошибки в Go могут служить точкой дальнейшего исполнения команды и не обязательно должны быть обработаны, как точка выхода
b) Вместо этого точка выхода это либо nil,  либо как в С-подобной программе - код выхода 0/1
с) Панику предлагают вообще не трогать без особого случая

Таким образом добивается устойчивость программ на Go и достаточная гибкость в обработке ошибок, как и их определении. Однако, бойлерплейта тонна и это раздражает, но эксперты говорили, что писать эти чеки в каждой функции - маветон.

?

Отсутствие дженериков - точно плохо. По поводу err != nil уже не так однозначно в сообществе.

Если верить их блогу, то исправление и того и другого должно быть в Go 2.0. Правда дату релиза несколько раз переносили, но все же надежда на 2к22 есть)

У вас уровень

Понимания

Смешно, Удачи с таким чсв.

Как-то смотрел интервью одного умного го разработчика. И он рассказывал, что на вопрос во время собеседований "чего по вашему мнению не хватает в го?" все тут же отвечают "женериков", а он в ответ просит привести пример задачи, которую они не смогли решить из-за отсутствия женериков в го. Ну и говорит, что никто не приводит.

Ребята не будьте типичными фроньтендшиками не сорьтесь

Конечно без них можно решить любую задачу. Вопрос в объёме кода

👌😀

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

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

Как очень плохонький

Отсуствие дженериков - это одно, а вот отсутствие дженериков БЕЗ альтернативы в языке, который постоянно используется для веб приложений, APIs и event-driven/reactive архитектурах - это уже реальная проблема, на мой взгляд, добавляющая существенный overhead.

контекст, короче

Edited: не говоря о том, что компилятор Go и так не разрешит много чего сделать, пытаясь эти дженерики изобрести заново

Это стоит посмотреть ))
https://www.youtube.com/watch?v=5d57lhnl25w

лично меня в го смущает тоталитарная императивность
не видел примеров хоть сколько-то декларативного кода на го
сложно представить какая там будет когнитивная нагрузка при разработке больших проектов