5 ms·
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 M
by izolate 2y ago
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.
- hnlmorg 2y agoI 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 2y agoThe "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.
- ARandomerDude 2y ago> 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 2y agoIn that case there's no particular reason to use them. As far as Go's philosophy goes.
- ARandomerDude 2y agotouché
- deleted 2y ago[deleted]
- zendist 2y agoIf you were to build a library like `rill` in the Go-way, what would your Batch API usage look like?