DEV Community 👩‍💻👨‍💻

Discussion on: 7 Easy functional programming techniques in Go

bootcode profile image
Robin Palotai • Edited on

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 for a balanced feedback.

Thread Thread
deepu105 profile image
Deepu K Sasidharan Author

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)