3 ms·
I'm not a Go programmer, but I think this is a problem of data structure expectations. Slices are not "lists", but views into arrays. So, by design, slices are
by scott_s 12y ago
I'm not a Go programmer, but I think this is a problem of data structure expectations. Slices are not "lists", but views into arrays. So, by design, slices are a view into contiguous chunks of values. In such structures, removing an item will necessarily be O(n).
A general principle in interface design for data structures is don't make expensive things easy. So, if removal from a slice is O(n), then the data structure is obviously not optimized for that, so don't provide a function for it.
- NateDad 12y ago+1 this is exactly it.
- bsaul 12y agoI would agree, except for the fact that slices have a lot of very convenient sugar syntax, making it look like the de facto standard for storing anything (with maps that is). Well, i may be spoiled, but ever since i stopped working with C, i never had to deal with data structure so different between arrays and list than go (that is, slices and container/list). The performance concern is an absolute hypocrisies. Whenever you decide which structure you pick in eg, Java, you know that the various containers are optimized for various operation, and you decide which to use depending on performance only. In go the language is so broken (because of the type system) that using a chained list vs an array makes your code look completely different.