Deleting an element from a slice is a O(n) operation. It better be explicit in the program so the programmer knows just how expensive it is. Either you know what you are doing, and then writing it down is trivial, or you don't know what you are doing, and you are creating an efficiency problem for the future. Other data structures have a delete operation because it is efficient on those.
And fully agree on the GC part. GC doesn't remove the work of resource management. It simplifies it vastly. This can some times lull people into thinking they can ignore resources altogether.
> Deleting an element from a slice is a O(n) operation. It better be explicit in the program so the programmer knows just how expensive it is.
The chances of deleting an element in an array being a bottle-neck are really low. I'd rather save my brain cycles for thinking about disk/network access and wait for profiling to show me the problem.
Agreed. And the fact that disk access might end up being a bottleneck is not a good argument for making disk access APIs less ergonomic. I say give the programmer the nicest set of tools possible and let them make informed decisions about what’s appropriate to use when.
Yeah, I'm on board with the idea that expensive or not-recommended operations should be more verbose to discourage them.
But you'll find other expensive operations (eg prepending an element to a slice) are much less verbose. At a certain point (of verbosity), you're just adding the potential for bugs.
But why does the strings package exist if it’s better to write out the for loop each time? Do you think there won’t be a slices package after Go gets generics?
The argument that writing out the loop is better for readability is just status quo bias. The real reason we don’t have standard functions for such things is a technical limitation that will probably be removed soon.
And fully agree on the GC part. GC doesn't remove the work of resource management. It simplifies it vastly. This can some times lull people into thinking they can ignore resources altogether.