In my opinion the two are very comparable. If filter() is more readable, it’s not by much, and this is all micro optimization bike shedding. I’ve never had a hard time using the idioms in a given language, and things like map/filter vs for loops were never what pushed me away from or pulled me towards a language. The important things are almost always learning curve, tooling, ecosystem, performance, maintainability, etc and Go does very well in many of those respects. The actual in-language features are generally just gravy.
Note that the Python people have map/filter/reduce (and have had them for ages) and no one uses them. It’s either for loops or list comprehensions, and people notoriously struggle with the latter.
The limitation to lambdas is just the single expression, but the same limitation exists for comprehensions. Comprehensions aren’t particularly readable beyond one loop and a condition or so (I say this begrudgingly as someone who likes to craft complex comprehensions). Beyond that for loops are encouraged, not filter() and friends, which suggests that they are perhaps not as amazing as some in this thread suggest.
Not if you're not used to it. Literally had this over the past few months working with a junior programmer who had a really hard time understanding stacked map()s and filter()s but understood them easily when I unrolled them into nested for loops.
The junior programmer would have been much better off learning how a filter function works so they could be productive in almost every other language besides Go.
This was Javascript. And yes, I was teaching him how filter functions worked. But the point remains that if you're not used to them, map() and filter(), especially when stacked, are not that readable.