>> Нули на позициях 2,4,8,16,32, именно тогда и проходили реаллокации. Но не суть)

Просто в качестве занудства: это только до 256 элементов в массиве. Дальше приращивается с шагом по 1.25.
Но действительно, не суть.

>> Потому что динамического размера массивы - вектора, изменяемого размера view на массив даже звучит дико

Вот именно поэтому, как мне кажется, молодежи с горящими глазами, несущими свет знания о динамических массивах в го, по ошибке названных срезами, нужно совершенно недвусмысленно доводить простую мысль: в Go динамических массивов нет. От "гибкого динамического представления элементов массива" меня тоже слегка в оторопь бросает, но суровая правда жизни в том, что слайсы - это именно оно и есть. Собственно, концепция слайсов не нова, она в том же Python'е во все поля есть. Специфика Go в том, что некий гениальный сумасшедший учёный запилил чудодейственный append, который позволяет этими слайсами через хитрозаверченную жопу сэмулировать поведение, издалека похожее на динамический массив.
По хорошему, нормальную реализацию бы запилить... Но, эту штуку придется согласовывать по поведению со слайсами, которые уже завезли... Решили, что и так достаточно изящно, на этом и успокоились.

>> Утиная типизация интерфейсов? Нулевые значения для всех типов? Конечно, хочешь отличать пустую строку и её отсутствие - заводи отдельную переменную/уводи её под указатель, что с nil интерфейсами может очень весело обсираться.

Ну, типобезопасность никто и не декларировал... К сожалению... Фишка Go, КМК, причина достаточно бодрого взлета, "в отличие от" - его УТИЛИТАРНОСТЬ. Вот прям девиз языка: УТИЛИТАРНОСТЬ. В Rust принято возбуждаться от КОРРЕКТНОСТИ, в Go - дрочат вприсядку на УТИЛИТАРНОСТЬ.
Ну, т.е., в своей нише Go, несмотря на всю общую "некузявость" подхода, вполне себе вне конкурренции.

>> Для языков со встроенной многозадачностью, в golang слишком просто получить data race/дедлок.

А вот этот пункт бы оспорил. Собственно, M:N, если мне память не изменяет, "искаропки" есть, собственно, только в Go и Haskell. В связи с этим сравнивать-то и не с чем, собственно. Да, в том же Python с M:1 или Java с 1:N дедлок словить сложнее... дык, они и M:N не умеют, а сложность имеет свойство возрастать квадратично. Так что в Go еще вполне себе ничего, могло быть сильно хуже.

>> Менджмент пакетов, if err != nill {return err}, дичь с монотонным и wallclock временем, процессоры кода смотрящие на комментарии и игнорирующие их в случае ошибки, реализация unionов через структуру с одним заданным полем... И это лишь то, что я сходу помню и не поленился написать.

Ну, как говорится, жить можно. Примерно такой же списочек можно на любой, имхо, язык написать. С единственным нюансом: if err != nil - то за что? Ну, нет исключений. Ну, их много где нет, да и сама по себе концепция исключений достаточно перегруженная, а некоторые реализации (кто сказал Java) - монструозны и вылазят лютейшим боком спустя десятилетия. Обработка ошибок - тупо данность, не хорошо и не плохо. Что лучше "if err != nil" на месте, или "иерархия классов исключений" где-то хрен знает где в спецификации языка - вполне дискуссионный вопрос.

>> Конечно, внимательное чтение документации по golang делает может спасти от многих проблем, однако никто не идеален, все допускают ошибки, и язык должен предотвращать как можно больше из них, с чем в golang ситуация обстоит ужасно.

Поэтому, видимо, в golang и не тащат все, что блестит. А язык... Язык должен закрывать потребности в своей нише. Гоша справляется, и достаточно хорошо справляется, с очевидными "продаваемыми" фичами.
Доказать менеджменту, что "надо дать денег, чтобы переписать на Go. На этом мы сможем выключить 89 серверов из 100, и сэкономим 80% операционного бюджета" гораздо проще, чем "надо дать еще больше денег, чтобы переписать на Rust. На этом мы сможем быть уверены, что наш код корректен" (угадайте вопрос, который вам менеджмент задаст сразу после этой фразы!)

>> В golang решили упростить множество вещей, чтобы они "правильно" работали в большинстве случаев, однако в остальных случаях код просто молча начинает работать некорректно

Да не, код ВСЕГДА работает корректно. Просто молодежь раз за разом наступает на грабли типа "слайс - это динамический массив" (грешен, сам наступал, сам так думал, был искренне удивлен, когда понял, что это не так). Почему она так думает? Ну, собственно, оно издалека очень похоже. А еще специалист, как правило, парочку соседних языков щупал. Вот собственно вектор примерно везде одинаково и работает. Вот и специалист думает, что "вот эта блестящая штука выглядит как вектор, наверное это вектор". На возражения - отмахивается, мол, "у нас тут утиная типизация".
А утиная типизация - это "выглядит как утка И крякает как утка". Выглядит оно как утка, а крякать-то и не умеет(. Вот именно слайс - самая проблемная для ПОНИМАНИЯ вещь в Go. Но язык УТИЛИТАРНЫЙ - ничего не изменится. Хотя вектор накидать можно минут за 10 - дженерики-то подвезли уже.
В общем, код-то работает КОРРЕКТНО, просто не так, как ожидал тот, кто его написал, опираясь на неверные представления о том, что пишет... Больно - да. Справедливо - тоже да. Что делать? - да хз. Когда это починят? - никогда.

Просто вы целый воз недостатков вывалили (и они, в целом, все есть, даже особо спорить не буду, хотя лично я часть этих недостатков недостатками не считаю). При этом в Go есть две вещи: горутины и каналы. Вот это - те самые две штуки, за которые языку прощают весь ваш список, и еще много чего сверху простят. Так что за дизайн ругайте, пофиг ваще. А про многозадачную асинхронность - не смейте! Руки прочь от СВЯТОГО!)))