4 ms·
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
by allyjweir 3y ago
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 https://github.com/samber/lo
- fifilura 3y agoThank 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.