They are, but also very difficult to work with. For example, removing an element is a copy, followed by a slice notation. Inserting is combination of appends and slice notation. You don't get simple methods like insert(index,item). Also if you are growing the slice in a function, you need to find a way to return the possibly new slice variable since append might need to realloc so you often have to resort to using pointers to slices as inputs. They just aren't easy to deal with.
And you can have memory leak issues if you forget to zero a reference since the backing array still holds the reference. And none of that is efficient. A lot of temps and unnecessary copying going on.
> You don't get simple methods like insert(index,item).
This is by design, to lift the CPU and allocation costs to the foreground. You can argue that was a bad design decision, but it wasn't an oversight, as you imply in the OP.
So the AOT makes that more difficult I'm guessing? I think that go does heavy lto so shouldn't inlining at link time give the same opportunity for that?
Java's escape analysis has always been dodgy to rely on. I've had some very simple code when I couldn't for the life of me figure out why the allocations weren't being hoisted. So I don't know if gos is better or worse.
It most definitely was not an oversight, clearly intentional but I think the issues could have been solved in better ways. Better use of lto and intrinsifying some functions in slices would help a lot.
Vector operations are extremely common. Go's making them difficult to use and refusing to optimize them (lto, intrinsics, etc) just seems poor.
PS: because of the score of my top level comment I've been rate limited pretty aggressively and can't respond anymore.
(edit: exactly what sagi said, only more long-winded) :
Removing an item from a list (that is actually performant enough that you'd want to use it) in Java is also a copy though, unless you're removing the last element. Underneath the hood, there's a copy. Same deal with insert.
Given the number of times I've seen insert or remove used where it really, really shouldn't, I'm not so sure the lack of insert/remove is a bad thing.
But yea I do get that general feeling that golang sort of... distrusts the programmer. Like the opposite of C++, where it assumes you're God, but then happily vaporizes you with God-powered-lasers.
> Given the number of times I've seen insert or remove used where it really, really shouldn't, I'm not so sure the lack of insert/remove is a bad thing.
Heavy reliance on such, as if they were free, is a very scripting-language thing. They hide all the grossness of such operations at the cost of significant memory bloat and inefficiency with simple, known-size structures (in order to make the more dynamic style run semi-fast at all).
There's no magic, and none of it's free, it just feels like it when you're push() and pop() and insert()ing all over the place. Making string manipulation closer to its roots as an array is also nice, in Go. If it's not worth bringing in a whole heavy library to deal with the awkwardness, then it wasn't worth writing the code that way to begin with. Figure out your lengths, resize as little as possible. Abuse and/or ignorance of how this all works is a big part of why we Can't Have Nice Things (performance, battery life) in the Age of Javascript.
Heyyy another thing (and certainly I've done this myself) used incorrectly in such a way that it is extremely expensive. Specifically, concatenating log strings inside a large loop in some handler, and then not actually using those log strings because the production server didn't log down that low - but still incurring the cpu cost of the string concatenation.
Are go slices not dynamic arrays? They grow automatically when necessary.