[fifilura]

I am not a functional programming fanatic, but I do appreciate all the functional constructs making their way into less esoteric languages. Such as map/reduce and in general working with immutables.

Golang does not have this and it makes me feel like programming with only one hand. In particular when working with data and aggregations.

I am prepared to be corrected, I have only looked briefly at golang, so I am happy to give golang proponents a chance to shine!

[allyjweir]

I felt very similar when I started working in Go last year. Coming even from languages like Typescript and Python which are most definitely _not_ functional but do have some of the niceties like map/filter/reduce, I was missing it a lot in Go.

What I also found was that there was a whole class of errors that I hadn't seen in years due to mutable state and poorly written for loops/ranges when compared to map/filter/reduce usage.

We introduced `samber/lo`[1] which provides a lodash-like library, generics compatible, to Go. This has been a big step-up and has improved my experience with writing Go immeasurably.

My colleagues now (kindly) joke every time they see a PR from me that includes a lot of samber/lo usage that I'm slowly replacing every for loop I encounter.

[1]: https://github.com/samber/lo

[fifilura]

Thank you! I will probably use it when I run into golang again.

I am with you. Ever since working extensively with SQL for a while my go-to paradigm has been "programming without for-loops". It just magically removes the bugs.

The problem here, as you also hint, is that there will be a clash with the existing culture and codebase. And that may not be a small thing, even though you co-workers seem to treat you in a good way.