> Простите, чуть-чуть поправлю: не в 2, там по дефолту в полтора, вроде.

Я пример кода скинул, который демонстрирует это

> → 0 0 1 0 1 1 1 0 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1

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

> А вот тут не понял, вектора тут вообще каким боком?

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

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

Я не говорю что Rust не имеет косяков, однако в нём никогда не делали вещи намеренно некорректными ради "простоты", и не забивали на достижения в языкостроении совершённые с 1980х годов. Утиная типизация интерфейсов? Нулевые значения для всех типов? Конечно, хочешь отличать пустую строку и её отсутствие - заводи отдельную переменную/уводи её под указатель, что с nil интерфейсами может очень весело обсираться. Для языков со встроенной многозадачностью, в golang слишком просто получить data race/дедлок. Менджмент пакетов, if err != nill {return err}, дичь с монотонным и wallclock временем, процессоры кода смотрящие на комментарии и игнорирующие их в случае ошибки, реализация unionов через структуру с одним заданным полем... И это лишь то, что я сходу помню и не поленился написать.

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