filter/map/reduce are more productive than anything I could write without them.

I’m very skeptical. This kind of argument only makes sense if your programming is bottlenecked by your typing speed. It’s trivial to write these functions as for loops, the only difference being the number of key presses.

filter is obvious at a glance, where all loops look similar. Generating a wall of boilerplate is easy, the problem is that we can’t just ignore it and read a summary. Essentially I’d like to decompile Go to what could have been written in a powerful language.

Wall?

    var out []X
    for _, x := range elts {
        if condition(x) {
            out = append(out, x)
        }
    }

That’s so easy I typed it from my iPhone and anyone looking at it can infer at a glance that it’s filtering a list. If you are deeply worried about it, throw a comment at the top of the block.

I too like terse code, but it’s because it makes me feel smart, not because it’s easier to read or more maintainable. I’m having a blast writing Rust for my hobby project, making everything super DRY and free from boilerplate, but I don’t pretend that I’m saving myself time or making things more readable or maintainable should someone else come across it.

elts.filter(condition(x)) way more readable.

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.

That's because in Python comprehensions have better ergonomics than lambdas. Scala has comprehensions too

  for { i <- 1 to 10; if i % 2 == 0 } yield i

but sometimes lambdas can be cleaner

  1 to 10 filter { _ % 2 == 0 }

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.

Only if you know what a filter is and how the condition is parsed.

In more cases than one the condition is a lambda-monstrosity shoved in the filter function, which makes it even harder to parse.

In the situation, even for statement also become monster.

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.

Then you can go ahead and use one of the many code generation libraries out there to handle it for you in a type-safe way.

Here are three options that were on the first page of google:

* https://github.com/kulshekhar/fungen

* https://github.com/awalterschulze/goderive

* https://github.com/cheekybits/genny