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.
