FuncFrog VS gofpher

func GetIDs(...) ([]string, ...) { <...> users := GetUsers(...) return ff.Map(users, domain.UserGetID).Do(), ... } ``` Now it's that easy! Furthermore you may like to write gogenerate function to generate such methods for each domain struct. Also there are more cool features, minimal-lock parallelism, error handling etc. in the libtaty https://github.com/koss-null/FuncFrog Cheers!

if it have to be in FP style, this one is better

https://github.com/koss-null/FuncFrog

still prefer non-FP part tho

Hi there! I have finally released a stable version of my stream-like library. It supports some basic features such as Map, Reduce, Filter, Sort, Any, First on any slice or generating function, easy out-of-the-box parallelism with minimum locks and overhead on a regular for cycle. Here it is: https://github.com/koss-null/FuncFrog First of all I will appreciate any code review. Any feedback are welcome. At second, I want to ask the community, what features do you expect to be in such kind of a library and how do you expect them to be implemented? It looks like I need to add some Collect function to be able to produce not only slices, and also add some sources such as BufferedReader or channel.

Hi gophers! In last months I've been working on a FuncFrog - java stream-api - like library, which is fast, parallel, lazy-evaluated and generic-based! You can check it out here: https://github.com/koss-null/FuncFrog

Check this out. I will be glad to any comments and notes https://github.com/koss-null/lambda/tree/0.3.0

I am rly strugging with it developing this:https://github.com/koss-null/lambda

Hi! Some te ago I've released the first beta of my stream-api like library. It have become much more useful and stable since then. Here is is: https://github.com/koss-null/lambda

Check the code out here: https://github.com/koss-null/lambda

I'm glad to see this idea getting some traction again. I haven't used Go much in the last few years, but I started writing playing around with a similar idea back in 2016 when I was working on a small compiler for a configuration management tool, and later put together a [small stand-alone proof of concept library](https://github.com/rebeccaskinner/gofpher) as part of a [talk](https://speakerdeck.com/rebeccaskinner/monadic-error-handlin...).

At the time, I remember finding FP in go surprisingly ergonomic. Implementing the library to support it was a pain since the type system wasn't expressive enough to prevent everything from devolving into a pile of untyped reflection, but it was reasonably easy to keep that an implementation detail. On the whole, I felt like go would have lent itself well to the "dash of FP for flavor" style of programming that seems to be gaining popularity these days. Unfortunately, in 2017 at least, the Go community seemed to have very little interest in the idea.

I still have a fondness for Go. It always felt nice to use. If the language features have caught up to the point where a robust library like this is feasible, and the communities attitude has shifted, I might take another look at the language.

Monadic error handling like in ML work-alikes, Rust etc. would be a good start. Adopt:

• https://github.com/rebeccaskinner/gofpher

• https://speakerdeck.com/rebeccaskinner/monadic-error-handlin...

I've been talking to the local Go user group. No one even knows about that concept. This continues a pattern of general ignorance/lack of looking beyond one's horizon I've noticed.