I’m still not sure what it is about slices that feels weird to you, but while they’re different from, e.g., lists in Python or List<T> in C#, etc., they seem intuitive to me, but I’ve been using them for years .
That’s extremely unlikely since this (the 3-index slicing) has been in Go for nearly 10 years. If everyone wanted it changed, then either the language would have changed (requiring a v2) or it would have died long ago. You still haven’t clarified what you don’t like. If modifying the capacity were the default, then there would be much more memory allocation churn, copying, and GC. FWIW, in my eight years of coding primarily in Go, I have almost never used the 3-index slicing. Almost all my operations that would change the capacity use append. Usually I specify the necessary capacity in make.
./prog.go:8:22: invalid argument: cannot make int; type must be slice, map, or channel
Instead, var arrOne int gives an array of length 4.
These are not arrays, so you shouldn’t name them as such. Go arrays have a size fixed at compile time. Passing an array copies the entire array. Go slices are view of arrays, so thinking of them that way helps to fully understand them. They also happen to be cheap to pass because copying them does not copy the element data. You get a new view of the same backing array.