In a nutshell, map, reduce, filter, and function composition are all generic functions, in exactly the sense of generic that Go doesn't have. Lacking all those things, trying to do FP in it is a waste of time. Lacking this foundation, most higher-level FP stuff is also a waste of time, unless there is some other path to it. Even if Go some day picks up generics and gets map, reduce, and filter, my guess is that function composition will never be something you can do in Go.
Note that it does have closures, and makes heavy use of them. It just managed to pick up closures without picking up the rest of FP.
I think this generally fits into the spirit of Go being a really good language for working in a larger development environment, where you can't expect everyone to be expert FP programmers. And, honestly, an intermediate FP programmer is sorta dangerous to your source code, in much the same way an intermediate OO guy is. Go does a surprisingly good job of preventing the intermediate guy from messing up your code too much.
To expand on what I said about the principles of FP being helpful to me in Go even so, here's an example: http://www.jerf.org/iri/post/2923 In theory, there's nothing that prevents another OO language from doing that, but without the structural polymorphism that Go has with its interfaces it's so much less convenient that nobody does it, and, more importantly, nobody thinks that way.
In fact, in some sense I'd say Go is inspired by CSP, but to the extent that CSP involves the creation of these complicated networks of data flowing around, it doesn't really do that. On the other hand, I'm not convinced that's a very practical way to program... complicated networks just become one more source of "magic" in a program. Using CPS-esque tools to make it easy to connect components together is itself pretty powerful.