destel

7 ms·

31.
by destel 2y ago
The short answer would be: I kept writing a code that spawns goroutines, that read from a channel, do some processing and write results to another channel. Add some wait/err groups to this and we'll get a lot of boilerplate repeat
32.
by destel 2y ago
I've just pushed few small changes to the readme that better explain context usage
33.
by destel 2y ago
I've also just pushed few small changes to the readme that clarify this things.
34.
by destel 2y ago
Thank you for the feedback. My design decision is of course a tradeoff. When multiple channels are exposed to the users (not encapsulated inside the lib), this forces them to use "select". And this is very error prone in my exper
35.
by destel 2y ago
Rill might look like it tries to be a replacement for iterators, but it's not the case. It's a concurrency library, that's why it's based on channels
36.
by destel 2y ago
It will. Otherwise the example wouldn't make sense. There's one important detail I haven't clarified enough in that part of the readme. For proper pipeline termination the context has to be cancelled. So it should have been b
37.
by destel 2y ago
For now, the library is context-agnostic by design. For HTTP timeouts, you'd use Go's standard approaches: either set the HTTP client timeout or pass a context with timeout to each request. Please let me know more about your use c
38.
by destel 2y ago
No, it's the opposite - the library treats channels as streams, processing items as they arrive without needing to know the total size in advance. This is why it can handle infinite streams and large datasets that don't fit in mem
39.
by destel 2y ago
I am thinking on it. To be honest, the current design works fine for my use cases: simply put, the function that defines a pipeline should have context.WithCancel() and defer cancel() calls. I need a feedback on this. What kind of builtin c
40.
by destel 2y ago
The lib is based on channels and inherits the channel behavior in terms of backpressure. Simply put if no-one reads on one side of the pipeline, it wouldn't be possible to write anything on the other side. Still, it's possible to
41.
by destel 2y ago
Hi everyone. Posting on HN for the first time. I'd like to share Rill - a toolkit for composable channel-based concurrency, that makes it easy to build concurrent programs from simple, reusable parts Example of what it looks like:
42.
Show HN: Rill – Composable concurrency toolkit for Go(github.com)
208 points by destel 2y ago|122 comments