Map filter and reduce are generic tools that can be accomplished through constructs Go already has. The point of Go is that most applications do not need a high level of abstraction, they are bounded problems. Go is also reflecting the Unix philosophy, no surprise given its authors, of building small focused tools. Therefore framing problems in terms of generic data transformations facilitated by mapping and filtering is drawing attention away from the concrete solution and making the code less clear.
I would actually argue that map and filter are perfect examples of unix-style, focused tools. They are the programmatic equivalents to sed and grep. Of course more specific tools can be used, such as cut or tr, but in most cases sed is fine and you just go with that. I definitely understand people wanting the same ease of use, even as a Gopher myself.
Reduce is a bit different though because the closest equivalent on the cli is awk with a BEGIN and END block, so it's a bit more high-level. But there is still value in it.
The thing is most people who complain about the lack of those functions are not looking for fancy transformations: in most cases you want something as simple as "extract a field in each struct" or "keep if this field has this value". There even is sort.Search in the stdlib that has something in the same vein; surely something like
>Map filter and reduce are generic tools that can be accomplished through constructs Go already has.
They can also be accomplished through constructs Brainfuck already has. Actually any Turing complete language will do.
>Map filter and reduce are generic tools that can be accomplished through constructs Go already has. The point of Go is that most applications do not need a high level of abstraction, they are bounded problems.
map, filter and reduce are not "high levels of abstraction" any more than for or channels are.
>Therefore framing problems in terms of generic data transformations facilitated by mapping and filtering is drawing attention away from the concrete solution and making the code less clear.
The "concrete solution" being copy pasting code with a different type to filter a list for your types, and using a for loop instead of filter or map? Sounds more like Stockholm Syndrome.
