I don’t see why a well-built standard library would be in the way. In the case of delete, well write your own linear search if you are into, though it gets old imo fast.
But will you also write a sort algorithm by hand? Because I am fairly sure it won’t be competitive with a properly written one.
Also, what about function composition? Will you write a complicated for loop with ifs and whatnot when a filter, foldl and friends would be much more readable?
Go actually does contain a sort package in the stdlib: https://golang.org/pkg/sort/ with the most ergonomic function being sort.Slice
As for a complicated for loop instead of the functional equivalent: I too am a fan of functional patterns in this case, but the for loop equivalent in my opinion is just as readable in 99% of cases. A little more verbose, that's all. Matter of taste.
Seems to me there are a lot of different types of collections which all have a delete operation. Feels like go forcing you to hand roll a delete forces you to violate the principal that a bit of code should care as little as possible about things it's not about.
If code breaks because list is now a hashmap, that seems like an anti-feature.
I agree filtering and many generic operations on slices would be nice, I think they have plans for it once generics lands. I don’t agree they are huge problems though, they are much simpler than sorting algorithms for example (which are included).
A range vs a series of filtering operations is an interesting question in terms of which is easiest to write or, crucially, for a beginner to understand after writing - not convinced foldl is easy for beginners. If you like abstractions like that, Go will be abhorrent to you, and that’s ok.
It is easy to build your own filter on a specific type, I’ve only done it a couple of times, it is literally no more than a for loop/range. Where I have written extensions and would appreciate helpers in the std lib is things like lists of ints and strings - contains, filter and friends would be welcome there in the stdlib (I use my own at present).
For filter etc I think I’d use them but am not convinced they would change the code much - the complexity is in what you do to filter not the filtering operation itself which probably adds about 3 lines and is very simple (set up new list, add to list in range, return list). For example in existing code I have lots of operations on lists of items which sit behind a function and for hardly any of them would I delete the function and just use filter in place at the call site, because I have the function to hide the complexity of the filtering itself (all those if conditions), which would not go away. I wouldn’t even bother rewriting the range to use filter because it’s not much clearer.
