I agree with the author that Go is not as easy as Python or Ruby. However, the first example given is bad.
Running delete on a slice is the same as trying to delete an element of an array. It's the wrong data structure if you need that type of access pattern. That's why it's hard. You can cut a tree down with a hammer, but it's going to take a while and you're going to have some blisters.
Go has built-in linked lists. https://golang.org/pkg/container/list/
and I will agree, they're not as easy to use as other languages due to the lack of generics in go, at present. Using the list.* package requires type conversion to evaluate and pull values out of the structure.
I think it's fair to say that Go needs to do a better job explaining the list package or possibly including it in the "Tour of Go" guide. That might help avoid these misconceptions in the future.
I feel like the majority of the time you just have arrays or slices of a manageable size, say <= 25 elements, and you just want to delete an element from it. You don't care about performance because it'll be fast regardless and surely not the bottleneck of your program.
In my experience with Go, a lot of basic functionality is missing and requires you to write your own utility functions. And some things you would expect like mySlice.append(elem) are instead written mySlice = append(mySlice, elem) which isn't as elegant. Plus you have to remember it's not just append(mySlice, elem)
If there's a handful of open source utility function libraries, that will split the Go developer base, kind of like how you used to have both jQuery, Prototype.js, underscore.js and others in Javascript. They should have just standardized all the common functionality you'd want and in an intuitive way.
If the array fits in the cache, deleting from the middle of an array and copying all the subsequent elements one to the left is actually faster than a linked list.
I don't think the author was concerned with performance. I was providing the list.* type suggestion to make it easier to delete elements syntactically.
However, you're likely right for slices with len < 500 or so due to garbage collector churn on linked lists.
> Running delete on a slice is the same as trying to delete an element of an array. It's the wrong data structure if you need that type of access pattern.
If you keep deleting elements from arrays then maybe, but if you do so once in awhile the cache-friendliness and limited allocations overhead of an array will most likely come out ahead. Especially if you also want arbitrary access.
Removing an element from a linked list is cheap if you’re already at that element (assuming the node itself is exposed), but most operations are way costlier.
Delete on a not-too-long arrays is pretty cheap. Probably even better than iterating over a linked list, but of course it depends on the exact application.
Running delete on a slice is the same as trying to delete an element of an array. It's the wrong data structure if you need that type of access pattern. That's why it's hard. You can cut a tree down with a hammer, but it's going to take a while and you're going to have some blisters.
Go has built-in linked lists. https://golang.org/pkg/container/list/ and I will agree, they're not as easy to use as other languages due to the lack of generics in go, at present. Using the list.* package requires type conversion to evaluate and pull values out of the structure.
I think it's fair to say that Go needs to do a better job explaining the list package or possibly including it in the "Tour of Go" guide. That might help avoid these misconceptions in the future.