I can’t speak to Go, but I encounter this attitude in other languages where I have more experience. In one particular case, TypeScript, I have quite a bit of ex

I can’t speak to Go, but I encounter this attitude in other languages where I have more experience. In one particular case, TypeScript, I have quite a bit of experience “shoehorning” FP to very good results. I find the attitude tiresome. Sure, in an abstract sense, there’s “more” to FP than these common abstractions. But there’s also less: FP is ultimately about acting on values. The “functional” part is an acknowledgment that a “function”, in its mathematical sense, is the common abstraction which achieves that. Map/filter/reduce are no more fundamental to that than any of the typical academic concepts often found in ML-family languages. Nor, as a detractor on Twitter suggested to me recently, are persistent data structures essential. Values are the essential concept, and all else that FP offers are in service of that concept. You can apply the same principles in nearly any language. You may need to build up your own implementation of some common abstractions to benefit from them. You may find certain patterns inherently awkward due to language semantics, or sometimes just syntax. Ultimately it’s still rewarding, from the perspective that one will be using said non-FP-paradigm language anyway. Because working with values is its own reward. And it’s incredibly rewarding, even if limited. I don’t think it does anyone any good to gatekeep that on the basis that the compromise… is a compromise. Sure, it’s worth pointing out that there are limited benefits. But none, in my experience, so limited that they negate the benefit entirely.