I don't think any of this actually goes against Go style. What makes you think this is against Go style, Go supports recursion and hence you can always choose between looping and recursion based on the use case. Lazy eval is the only thing that looks hacky IMO, that's why I mentioned to use it only if the methods are heavy.
You are right, I can't state it with a solid resource.
My impression about the language was that one of its intent is to keep code in front of the developer's face. Abstractions that introduce indirection are not as welcome as in, say, Java.
I would say the immutable data usage surely can't hurt. Other functional constructs deviate more from the KISS agenda of Go.
I don't say don't do it. As a mental exercise it is interesting. If your team is with you, sure. On a public project however, don't get surprised if selling the style would be hard.
Looking forward to your experience!
Edit: See twitter.com/bootcode/status/116161... for a balanced feedback.
FP can be useful as long as you don't overdo it. I personally like functional composition/HoF/closures and so on. Avoiding data mutation and using pure functions can only add value most of the times. Stuff like recursion, Lazy eval is definitely on a need basis and can be ugly if overused. But if you are coming to Go from a functional background you can always do things(almost) the way you are used to.
It's all about personal preferences anyway. IMO we should use good concepts from every paradigm(FP, OOP and imperative)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.