[izolate]

The batching concept is a cool idea and could be useful in the right context. That said, this feels like a JavaScript engineer's take on Go. Abstractions like Map and ForEach don't align with Go's emphasis on simplicity and explicitness. The lack of context.Context handling also seems like an oversight, especially when considering concurrency.

Judging by the praise, I'm probably in the minority, but as a code reviewer, I’d much rather see straightforward loops, channels, and Go's native constructs over something like Rill.

[ARandomerDude]

> Map and ForEach don't align with Go's emphasis on simplicity and explicitness

I've never paid my bills with Go, but `Map` and `ForEach` don't seem all that different than `for _, u := range Users` to me. Yes, the former is "functional" but only mildly.

[emseetech]

In that case there's no particular reason to use them. As far as Go's philosophy goes.

[ARandomerDude]

touché

[zendist]

If you were to build a library like `rill` in the Go-way, what would your Batch API usage look like?

[hnlmorg]

I don’t agree with your comment about Map and ForEach, just by virtue of the fact that sync.Map exists in Go’s standard library.

But your point about the lack of contexts is definitely a deal breaker for me personally too.

[akshayshah]

The "map" under discussion here is very different from sync.Map. The discussion here is focused on the "map" primitive from functional programming - transforming a collection by applying a function to each element.

sync.Map is a concurrency-safe hash map. Same name, totally different thing.