Hacker News Reader

Comment by alkonaut | Hacker News Reader

I'm thinking of the crowd that insists "map" is never more useful or readable than s straight for-loop. So not only don't they want it in go (which could be understandable in some situations), they genuinely seem to think it has no place in an imperative language. That blows my mind.

View on HN

I've written in both paradigms and I mostly agree with the Go team. That it blows your mind blows mine, and I suppose it's good that we have these choices so we don't have to agree.

Could you show me a code snippet of maps and filters used that you believe is more readable than for loops? Maybe I'll get a laugh out of that. :)

A for loop is a general tool. It can be used for anything. Because of that, it conveys little or no information. As a reader I have to read the loop in detail to see that what it does is perform a mapping, and not something slightly different (the last item could be skipped, etc etc).

The expressiveness of higher order functions comes not from terseness (only) but by expressing intent more clearly.

E.g this expresses (in pseudo) A conversion followed by a filter.

> odd_ints = strings.map(parseInt).select(odd)

This was expressed in the forum, but there was no agreement that this was readable, so I fully expect you to also think the for loop to be more readable. I suspect there is a divide between those who prefer reading how something is done rather than what is intended, in order to understand it.

Ok, that's a good example. Your one-liner is pretty concise and the intent is clear.

I think on a higher level with complex code, you definitely want better abstractions to convey intent, rather than say just having one large function that does everything.

I think in many cases map/filter does in fact help with readability of intent, especially if you're not declaring the function body inline, and the functions are commonly available ones like parseInt. But generally this isn't the case, which diminishes the readability such that it's comparable to a for-loop anyways.

I spend most of my time trying to figure out exactly that -- the higher level abstractions that aren't easily conveyed by "map" or "filter", that having map/filter generic functions isn't high on priority. I just want a simple language that I can spew out thoughts onto uncompilable code... tweak the code often as I see fit, and work on fixing type errors later and once I'm done with that it will probably run fine with few bugs. The nice thing about for-loops is that it exposes more control points e.g. breaking out early, using the index, inserting log lines -- that the flexibility helps me mutate the code quickly.

So maybe it's more about coding style, rather than readability. Do you like to spec out your code completely before writing things down, or do you prefer to define the spec as you write and edit the code because it helps you get things done faster?

Another data point for you (I'm not the grandparent poster):

I prefer to write exploratory code and spec out the design as I go along, and I also prefer map/filter (or list comprehensions) to for-loops.

I suspect it does have to do with coding style, but not in the way you suspect. I like to write very small functions - often one-liners, rarely more than a page - and have each function do one thing and one thing only. I also tend to code mostly bottom-up, figuring out what abstractions I need, writing them, and then writing the functions that use them. So I almost never use an inline lambda for a map, it's usually a function I've already defined.

All of the exploratory scenarios you list are handled by built-in functions in my language of choice (Python). Breaking out early = itertools.takewhile(). Using the index = enumerate(). Inserting the log lines, I'd just insert them in the mapper (although there's also trace).

Is there a reason you need some built-in map thing and not just user-defined functions? If a loop is too hard to read inline, you slap it in a nicely named function and now it's more clear and more concise. Either way, you have to write the code to do the conversion. select(odd) doesn't work unless you've already written the code behind whatever "odd" is, for example.

I can write go code that makes this line legal:

    odd_ints := parseInts(myStrings).select(odd)

but I'd probably write code so it looked like this:

    odd_ints := odds(parseInts(myStrings))

Is either of these harder to read? Does it matter that parseInts is a "map" and odds is a "filter"? Their function is obvious by their names. If anything, the words "map" and "filter" are extraneous.

they are so pervasive/important that it should be included in the core library. I'd include my own collection_utils every single time.

That said, having a library function of course requires it to work in a type safe way for all collections/functions, which might make this argument really be one about generics and not about two collection functions. If this is omitted because generics is, I think it's just another argument why omitting generics is making the language simple to the point of being stupid.

Instead of map/filter:

    // using some fake filter/map/lambda syntax
    names := machines.filter(strings.HasPrefix(m.tag, "ec2")).map(|m| = m.name)

why not just write

    names := []string{}
    for _, m := range machines {
        if strings.HasPrefix(m.tag, "ec2") {
            names = append(names, m.name)
        }
    }

What happens when you read that first implementation? Don't you read it as "for each machine, if its tag has the prefix "ec2", then append its name to the list that is returned? Isn't that the exact same thing you'd read the second one as? Except that the second one requires no special knowledge other than loops and if statements.

    let descending_squares = range(0u, 5u).rev().map(|x| x * x).collect();

versus:

    let mut descending_squares = Vec::new();
    let mut i = 4u;
    loop {
        descending_squares.push(i * i);
        if i == 0 {
            break
        }
        i -= 1
    }

(Note that if you try to use a for loop here you will infinite loop due to unsigned underflow.)

Well this is how I'd write it in Go:

  descending_squares := []uint{}
  for x:=4; 0<=x; x-- {
    descending_squares = append(descending_squares, uint(x*x))
  }

Use unsigned integers for your index and values. That's what makes it hard to use a for loop. (Sure, you could cast a signed integer loop index to unsigned inside the loop to avoid the underflow problem in this specific case, but I'd argue that the functional style is so much clearer than code that has to work around unsigned underflow gotchas.)

> functional style is so much clearer

There is something that makes me uncomfortable in there:

> let descending_squares = range(0u, 5u).rev().map(|x| x * x).collect();

The overhead. I wonder about it. I am unable to get a sense of what it is. With a simple for-loop, it's rather easy to see it, but with the version above I have no idea. So "much clearer" is not what I see with the piece of code above. I see what it does, but what is not so clear is what code will be generated, something which matters when trying to write efficient code.

There is not much overhead with Rust iterators at all. They are essentially concrete versions of the deforestation that Haskell can do to avoid constructing intermediate lists, and compile to code that is close to the equivalent C (the functionality is all statically dispatched, so the compiler can inline and optimise the calls). This is a case of having experience with and trusting one's tools.

I wrote a blog post a while ago that used iterators heavily http://huonw.github.io/blog/2014/06/comparing-knn-in-rust/ , as you can see the performance is good.

I am definitely going to have to look more into Rust.

Well then, good news! Such usages of iterators in Rust are almost always result in the same code that would be generated by old-fashioned, hand-written loops. The 'trick' is that the methods (and the closure!) are inlined, and generics are specialized at compile time.

All I did was take your for-loop code and translated into idiomatic Go code. My point is the for-loop in Go isn't as terrible as the loop example you wrote.

Your version infinite loops: http://play.golang.org/p/uglbTETE6d

See why for loops are tricky? :)

Doh! I fell straight in :)

Overflows in general are tricky. How does Rust deal with it?

We have special checked types you can use if you want checked arithmetic. The default is to not check, because CPUs currently make it expensive to check (although I would love it if that could change--we need hardware support though).

But CPU's have the overflow flag, that is actually set if the operation overflows?

You can't write that check explicitly in C, but you can in assembler. Available now, across the different hardware.

As you say, detecting the overflow is easy, but efficiently handling it is not. It adds a branch to every single arithmetic operation, and it makes it much harder for the compiler to optimise things e.g. it is hard to vectorise a loop summing an array, if every + has a conditional branch on the overflow flag.

(Also, I believe it introduces a lot of data dependencies, getting in the way of the out-of-order execution of modern CPUs.)

To handle the overflow on the places where you want to handle them, modern processor doesn't have any problem with an additional jump instruction. Also, modern compilers could optimize the checks away if they aren't used. In effect, implementing overflow checks definitely won't turn your C speed (1s) code in a Python speed (40s) code. I estimate it wouldn't be even two times slower in most of the use cases. It's certainly not the problem of the CPU's.

It can be the problem of the certain compilers if they don't have the infrastructure to reason about overflow flags though. But it's not a hardware problem.

> I estimate it wouldn't be even two times slower in most of the use cases.

In his "We Need Hardware Traps for Integer Overflow"[0], Regher quotes 5% to 100% overhead for languages such as JS or Racket, and that a "highly tuned" checker would likely be in the 5% range. Playing with arithmetics-heavy programs and Rust's checked_* (which are backed by LLVM's overflow intrinsics[1]) I got anywhere from 5 to 40% performance loss IIRC.

That's not a lot, but at the same time when you're competing with languages specifically not paying those 5%, a 5% hit on all computations is not going to get you much love.

Which is why Rust currently lets you do that (via num::Checked* and num::Saturating) but uses overflowing default semantics.

[0] http://blog.regehr.org/archives/1154

[1] http://llvm.org/docs/LangRef.html#arithmetic-with-overflow-i...

OTOH I must note that Swift, on the other hand, has opted to error on overflow and have a second set of overflowing operators: https://developer.apple.com/library/mac/documentation/swift/...

And that's the best approach I can imagine: programmer should be able to control if he wants 5% penalty or speed. It's a win-win.

> To handle the overflow on the places where you want to handle them, modern processor doesn't have any problem with an additional jump instruction

This isn't just a jump, it is a branch. Especially when the body of the loop is 6 instructions, adding an extra branch is going to be noticable.

> Also, modern compilers could optimize the checks away if they aren't used

This is equivalent to the halting problem, and most code will not be able to optimise them away. Suggesting otherwise is invoking "sufficiently smart compiler", which is invalid.

In any case, you haven't addressed the problem of missed optimisations (especially vectorisation) caused by having to maintain semantics.

> It's certainly not the problem of the CPU's.

Yes, it partly is: the data dependencies and linearisation caused by checking the CPU flags is bad.

Nice. :)

Just use int and it works fine: http://play.golang.org/p/nZcd3M5aL_

To me golang is readable while even small rust examples don't feel quite right right.

> Just use int and it

is a completely different piece of code.

I love when arguments are decided by/proven by runnable code examples.

Or if Go and Rust had a FOR loop guaranteed to stop at 0, as with a Wirthian language, no?

Aside from your specific point (which I liked), isn't there a kind of tension here in a systems language?

For loops are almost always going to explicitly show their allocations whereas the functional version has allocations that are not nearly as obvious.

None of the iterators in the Rust core library allocate. (In fact, they can't, since the Rust core library has no allocation—it's the building block for liballoc.)

You need a collect on that first example, you end with a Vec<uint> in the second, but an Iterator<something> in the first.

Oops, you're right. Fixed.

And that's why I like go.

Sorry, that's not really fair. I'm sure the compiler would have caught that when you tried to feed it into something that wanted a vector (or would have not cared if you were just iterating over it).

To be honest, I think Rust has a lot going for it. I just think Go has a lot going for it too... they're just different things. Which is fine, because if everything were the same, the world would be a really boring place. :)

Are you suggesting the Rust compiler didn't catch that?

No? I don't actually know rust, but I don't think the first thing he typed was invalid code. It just returned an iterator instead of a vector. I was suggesting that when he tried to pass the variable into a function that expected a vector, the compiler would complain. No snark, I just meant what I said.

To be fair, the line "And that's why I like go" seems to imply that Go is able to keep you from making errors in untested context-free code snippets. Perhaps you meant "and that's why I like that Go doesn't support operations like `map`"?

Well, yes, actually, Go does help prevent errors in untested context-free code snippets... by being really really simple, and not trying to mash a ton of logic into a single line for no reason.

The amount of language trickery is at a minimum with Go, so writing something out in plaintext often just works. It's hard to screw up for loops and if statements for people who have been programming for any significant period of time.

It's not that I like that Go doesn't have map, per se. I just don't miss it. At all. And the fact that it's not in the language means I don't have to read someone else's use of it and try to make sure they're not screwing it up somehow. A wise man once said "It's not that I don't want generics, I just don't want you to have generics."

  > Go does help prevent errors in untested context-free code 
  > snippets... by being really really simple, and not trying 
  > to mash a ton of logic into a single line for no reason.

But there is an example in this very thread of a manually-implemented map-via-a-for-loop from a well-meaning Go user that accidentally underflows into an infinite loop.

This isn't an attack on Go (which I respect as a language for having the temerity to be opinionated, a facet that more languages need to emulate), merely bafflement at your claim that implementing everything anew via bespoke loops is somehow effective at reducing errors.

Yes and that was a carefully constructed example explicitly to show problems with loops.... But underflows in loops are just not a common occurrence, which is why the example works in the first place.

> Yes and that was a carefully constructed example explicitly to show problems with loops

No, it was an example from my experience and a bug I have had to fix multiple times, as I mentioned. I didn't make it up.

Sorry, yes you mentioned that. Anyway, this is a stupid thing to argue about and I apologize for my part in it.

Likewise, forgetting a `.collect()` call in Rust code doesn't happen, because the compiler will tell you without fail when it's given an iterator but expects an array.

> Well, yes, actually, Go does help prevent errors in untested context-free code snippets... by being really really simple, and not trying to mash a ton of logic into a single line for no reason.

Sorry, I don't see the benefit of "preventing errors in code that's never actually executed" as a design goal.

> The amount of language trickery is at a minimum with Go, so writing something out in plaintext often just works. It's hard to screw up for loops and if statements for people who have been programming for any significant period of time.

I just demonstrated a counterexample in this thread.

That's the only place in C where I use the postfix decrement operator.

    for (u = 5; u-- > 0; ) {

Go is not the language for you if you care about mashing as much logic into a single line as you can.

Also, I can count the number of times in my 15 years of professional development experience that I've wanted to count down to zero using an unsigned int as the index... never. Which is not to say that the declarative isn't nice, just saying that the example of the infinite loop is not exactly compelling.

> Go is not the language for you if you care about mashing as much logic into a single line as you can.

The point here is that iterators can reduce bugs, independent of aesthetic concerns.

> Also, I can count the number of times in my 15 years of professional development experience that I've wanted to count down to zero using an unsigned int as the index... never.

I like to give that example because it was something I actually hit and a bug that I actually had to fix.

In fact I just hit that again yesterday when iterating over a list in reverse order (painting order for CSS box-shadow).

  > The point here is that iterators can reduce 
  > bugs, independent of aesthetic concerns.

Iterators can reduce bugs, really? This is a very flawed point. Bugs are not caused by lack of language features, they are caused by people. And people make mistakes independent of language features and sometimes because of language features causing cognitive overload or require them to make assumptions.

> And people make mistakes independent of language features

Unless language features prevent the existence of these bugs. Javascript will blindly let you concatenate a number and a string, Go will not. Therefore you can't make the mistake of unknowingly concatenating a number and a string in Go. Thanks to a language feature.

Iterators prevent indexing mistakes (off-by-one errors, index overflow or overflow, wrong-variable use), therefore iterators can indeed reduce bugs.

  > Therefore you can't make the mistake of unknowingly
  > concatenating a number and a string in Go.

Look at this another way: If you need to do that you now have to think about it and explicitly convert a number into a string. But while you are thinking about it you can make mistake of concatenating a number with a wrong string or make some other screw up, because your thinking power is now reduced.

> If you need to do that you now have to think about it and explicitly convert a number into a string.

You have to think about it either way, the feature precludes forgetting about it.

> you can make mistake of concatenating a number with a wrong string or make some other screw up

Which you can make in both cases.

> because your thinking power is now reduced.

Your thinking power is not reduced, it's increased: you don't have to wonder whether you should convert something to a string or it already is one, the compiler will tell you, so you can focus better on the actual work at hand.

No, if conversion is implicit you don't have to think which function to call, where to find it and which library to include. Quite significant cognitive overhead I'd say.

Having separate concatenation operator with implicit conversion could reduce that overhead:

  a := "foo" ~ "bar" ~ 123

Instead of:

  import "strconv"
  
  a := "foo" + "bar" + strconv.Itoa(123)

But this is not how Golang guys make decisions. And I'm fine with that nowadays as long as they don't claim to be right in that regard.

The interesting code for this example is:

  c := a + b

There's no indication from that line of code what a and b are, a type system that doesn't do implicit conversions will tell you "error: adding string and int" and so the programmer can address the problem (e.g. maybe they meant to parse an integer from the string `a`, maybe they meant to format the integer `b` into a string).

Using literals is not a useful comparison because there is no confusion about types in that case.

My bad, I thought it was obvious from having separate operator for concatenation that '+' operator also has only one intent. So in your case it will parse an integer from a string if operand is a string.

The way I see it is that you can reduce bugs by increasing the level of abstraction, which in this case means to use things that are more straightforward and less flexible: the ultimate looping-construct is arguably the while-loop, by using a counter to index into the array (if you're working with an array, anyway). But with that flexibility comes more room for error: maybe your increment is wrong, maybe your while-condition is wrong, maybe you inadvertently change the index inside the loop without meaning to, etc. A step over that is to explicitly just say that you want to iterate over each element in the array. You don't get to choose how, but you probably wanted to iterate over it from start to finish anyway. The highest level is a function that encapsulates exactly what you want without having to bother with explicitly iterating over the collection yourself. Now you can't even mess up how you use each member of the array, because that is already handled by the function.

A higher level of abstraction means less flexibility, which means fewer potential things that you can screw up. I don't see how that is a flawed point.

Well, the way I see it has nothing to do with levels of abstractions or flexibility, but everything with reducing amount of brain power required to understand the program. Sometimes abstractions do help, other times they add unnecessary complexities and reduce people's brain power to understand the rest of the code and therefore make mistakes in it. This is all about psychology.

Sorry, if I was rude, I'm just tired of pseudo-scientific language designs.

It's a question of which you prefer: declarative or imperative. Having that in mind, and knowing that "readability" is a tricky concept, here is an example in LiveScript:

    # utility, normally wouldn't be here
    map2 = (f, xs, ys) ->
        map (apply f, _), (zip xs, ys)

    startsWith = (prefix, str) ->
        map2 (==), prefix, str |> and-list

    endsWith = (suffix, str) ->
        revStr = unchars << reverse << chars
        startsWith (revStr suffix), (revStr str)

"<<" is function composition, "|>" is a "pipe" or "reverse application order operator", "_" is partial application. "map", "zip" and "apply" functions are standard and have expected semantics, "chars" transforms a string into an array of chars and "unchars" does the opposite (and they all come from prelude-ls library).

This code is both shorter and easier to read (to me, at least) than equivalent for loops and it also composes better. The details of iteration are irrelevant here and so are abstracted, which means they can be trivially changed.

Of course, for "map" to be this useful it needs to be supported by many functionally oriented language constructs. It's also not the best example for anything, it's just a piece of code I wrote in a style I like, in a language I use.

Semantically, loops impose order, maps do not.

A map can be auto-parallelised.

A loop cannot.

It seems to me that for a language aimed at exploiting concurrent features, easy wins for parallelisation would be a feature.

There's really nothing about a typical map operation that makes it any more parallelize-able than a for-loop, in the presence of closures.

The article is about Rust. In Rust, the type of the closure indicates whether it can mutate externally visible data (and therefore race on it).

Having just started reading the Rust guides, I'm curious: can the closure type actually ensure it doesn't mutate any externally visible data, or does that only apply to memory? Can declare that a closure doesn't (or shouldn't be allowed to) write to disk or hit a database?

Gotcha! So will Rust then auto-parallelize these "pure" closures?

We'd like to have generic APIs in the future that will allow idiomatic automatic data parallelization. Niko Matsakis has been thinking about this for quite a while. Stay tuned :)

(Note that Servo has been using this type system feature for a while now to prevent data races in our massively parallel CSS layout code.)

> Niko Matsakis has been thinking about this for quite a while. Stay tuned :)

Arrg, you have me excited now!

I wouldn't put my hopes very high on this. They tried doing this kind of ubiquitous automatic parallelization in Haskell but they ran into parallelization overhead issues because its very hard to have the computer figure out the correct parallelization granularity all by itself.

Amdahl's law says auto-parallelising a map operation is usually a big waste of time.

Who is Amdahl, why should I care, and does he expand on this argument or is it your interpretation of a more generalized law?

Going to search for it, but I'd still like to hear your response.

The application in this case is that the mapped operation generally has a fairly low cost and the (sequential) cost of dispatching and resynchronising back into a result are going to dwarf any gain you'd get unless either the collection is huge (and the parallelization is coarsely chunked) and/or the mapped operation is extremely expensive.

Same reason why even though mergesort is fairly trivially parallelizable there's basically no stdlib running parallel mergesorts by default: you need huge collections before you recoup the synchronization overhead.

Your collections don't have to be stupifyingly huge for a parallel mergesort to be faster. It's bad for a standard library to auto-parallelize because that's an unwelcome side effect. If you're writing some program where you actually cared about the performance speedup, in most cases having a sort function spawn threads or use threads behind your back in a way that your system can't control is completely unwelcome.

Have you rung up the GPU manufacturers to tell them that they're wasting everyone's time?

The synchronisation/set-up overheads are still fairly large (e.g. communicating with the GPU). I find it rather unlikely that e.g. a map over 20 elements will be faster in parallel.

It might not be. But I am happy to ignore the question and leave it to the compiler or runtime to take advantage of easy parallelism. Maps allow that, loops (or any other sequential treatment of data) doesn't.

My personal brand of bigotry is relational databases, so I am accustomed to thinking of sorted / ordered behaviour as the special case. Thinking in sets is very powerful.

It doesn't have to be either/or. Sometimes you need a loop. But it would be nice to have mapping too.

Let's take the example interview question: given a string, how do you determine if it is an anagram of a palindrome? The answer is that, for any given character, at most 1 should appear in the string an odd number of times. Here is an implementation in Scala, with higher-order functions:

    def isAnagramOfPalindrome(s: String): Boolean =
        s.groupBy { c => c }
            .map { case(key, value) => value.size() }
            .filter { n => n % 2 != 0 }
            .size <= 1

And here's a more traditional implementation in JavaScript.

    function isAnagramOfPalindrome(str) {
      var chars = {};
      for (var i = 0; i < str.length; i++) {
        var char = str.charAt(i);
        chars[char] = (chars[char] || 0) + 1;
      }
      var numOdd = 0;
      for (var key in chars) {
        if (chars[key] % 2 != 0) numOdd++;
      }
      return numOdd <= 1;
    }

I find the Scala version much more readable, but I'm assuming you'll prefer the JS version?

In Go:

  func isAnagramOfPalindrome(str string) bool {

    charCounts := map[rune]int{}
    for _, c := range str {
      charCounts[c]++
    }

    numOdd := 0
    for _, count := range charCounts {
      if count%2 == 1 {
        numOdd++
      }
    }
    return numOdd <= 1;
  }

In this case I think I do prefer the latter. I like how I can name the intermediate objects. :)

Also I don't like the practice of groupBy().map(=>_.size()), which hides the performance penalty of creating arrays. I'm sure a better compiler can do better, but I'd have to know the compiler to assume that.

I'll bite. In Python:

    def odd_count(letters):
        return lambda ch: letters.count(ch) % 2

    def anagram_of_palindrome(letters):
        return sum(map(odd_count(letters), set(letters))) <= 1

How's that for some higher-order function action?

But really, unless you are deriving programs by doing algebra you are missing the point of things like map() and reduce() (as far as I know no one is actually doing Functional Programing the way Backus described. Am I wrong? I'd love to be wrong.)

Go read Backus' Turing Award paper: http://web.stanford.edu/class/cs242/readings/backus.pdf

The Haskell programmer in me can't resist---eta reduce your functions! :P

    from functools import partial
    
    def odd_count(letters, ch):
        return letters.count(ch) % 2
    
    def anagram_of_palindrome(letters):
        return sum(map(partial(odd_count, letters), set(letters))) <= 1

A more modern take would use collections.Counter(letters) to extract the letter counts, that avoids traversing the string for each letter count:

    def anagram_of_palindrome(letters):
        return sum(c % 2 for c in Counter(letters).itervalues()) <= 1

The discussion here has been good, and the thread is already old, but I can't help myself!

Maps, filters, folds provide a vocabulary for manipulating entire collections. They allow you to write code for transforming the individual items of a collection without mixing it with code that deals with the shape of your collection. Maps, folds, and filters exist for trees and all kinds of other structures with interesting shapes that are more challenging to traverse and reason about than a simple array or list. Languages with first class support for these operations provide a common vocabulary for processing collections of any shape. This alone is a good enough reason for me to prefer such languages, even without bringing readability into the mix.

I also think that it is usually possible to write code with maps and filters that is at least as readable as its for loop equivalent, especially with the comprehension sugar commonly found in many functional languages.

I also agree with the Go team. Although I am a big fan of functional language constructs like map & filter, adding them to Go does not feel right. One of the great things about Go is that it's simple but it does not hide much from you. You still know exactly what is going on (concurrency& channels being an exception). That's why I find it easy to read Go code.

The go community reminds me of the java community. Blind faith in the design decisions of the language. Any feature it doesn't have is passionately defended as a good decision because the clumsy old way is subjectively clearer, up until the day it gets added.

I found that attitude much more prevalent in the .Net community: for just about anything added since C# 2.0 (I didn't follow discussions about generics after the 1.0 release though I expect it also happened then), the idea was essentially dismissed as pointless ivory-tower wankery useless to developers in the Real World right until MS announced it for the next version, at which point it became an Obviously Great idea and a good way to trash-talk java.

That sort of behaviour is in no way unique to Go or Java, and I think it's unfair to judge a language or community by some posts from an online newsgroup - most people are too busy to post or lurk on lists like golang-nuts.

mapping and filtering are just functions and/or loops. You can write those in go. Making some generic thing to save you 3 lines of (really simple) code is not an incredibly useful use of the Go author's time.

I don't get the sense that they think it has no place in an imperative language. Like the OP calls out, Go is a very small language with few constructs. For a lot of tasks there are simply only one way to do things. Some would consider this a strength, others a weakness (kind of like Python vs. Perl).

Reply on news.ycombinator.com