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.
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)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While I like FP, these practices go directly against Go style. If someone applies this FP style, reviewers will be very unhappy.
In Go, a for loop is a for loop, they would say. They would even be bity for pulling a for loop out into a method sometimes (let alone recursion).
Based on my own experience as a novice writer of occasional Go code.
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)