Early exit optimization for .First?

[danthegoodman1]

Was reading through the README and saw:

https://github.com/destel/rill?tab=readme-ov-file#order-preservation-ordered-fan-in

Here's a practical example: finding the first occurrence of a specific string among 1000 large files hosted online. Downloading all files at once would consume too much memory, processing them sequentially would be too slow, and traditional concurrency patterns do not preserve the order of files, making it challenging to find the first match.

But this example will process ALL items, it won't break when a batch of 5 finds something? It seems in this case where you only care about the first found, and the inputs are ordered, then early exit would be far more beneficial. Or does .OrderedFilter lazily process and the .First actually executes it/early terminates all remaining work when a first exists?

[destel]

@danthegoodman1
Thank you for the feedback. First returns on the first match. I have just updated the Readme and examples to clarify this. Could you please take a look and let me know if my updated explanation works?

[danthegoodman1]

I think so? To make sure I understand, OrderedFilter is non-blocking, and First is blocking? I know it's mentioned in pieces above, but might be good to say "This is because OrderedFilter is a non-blocking operation, and First is a blocking operation".

[destel]

Yes, you're right: OrderedFilter is non-blocking, and First is blocking. I'll think on how to make it more clear in the readme. One option I am considering is to add a small flow diagrams/animations to each example. But this would take some time of course.