go-iterator VS lo

I already played around a bit wit the beta a while back and made an iterator library to get to know this new language. It's here for anyone interested: https://github.com/polyfloyd/go-iterator

Regarding call chaining, it is still possible to chain things with operations that return different types, but they have to be done with functions instead of methods, so the result is still the same, just it's a little less readable. There is a generic iterator implementation by polyfloyd that doesn't support method chaining, but imo being able to chain iterators is one of their biggest strengths, since implementing lazy evaluation manually for a single operation isn't that difficult, its when you need to perform multiple kinds of manipulations that it gets messy.

There is, in fact a Lodash-like package for Go: https://github.com/samber/lo

What's really maps and filters? All I see is loops hidden in JavaScript runtime with different names but yes, it doesn't hurt to write few readable Go code for every project, when I started Go I used something like Samber/lo this is a worthy competitor you can install in every project and make use of it😜, another thing is: you have pure go code (no type definitions) so you can easily jump right into the code to see how it's done and learn

This library is useful even in testing https://github.com/samber/lo

If you are curious, try looking at github.com/samber/lo and github.com/samber/mo packages if you get a chance.

mostly this https://github.com/samber/lo

Any different then what is provided by https://github.com/samber/lo?

otherwise this library has some success for some operations: https://github.com/samber/lo - it's a bit of tooling around searching/filtering and such, you'll need to dig a bit more if you need vecdeque, heaptree and such.

case in point, lo

I rarely implement generic struct or method my own. But i use https://github.com/samber/lo quite a lot for slice/map manipulation.