I made this "expert-friendly" doc, to orient all who find themselves probing the Java Streams source code in despair. It culminates in the "Stream planner" - a little tool I made to simulate how (parallel) stream operations affect memory usage and execution paths.

Go forth, use (parallel) streams with confidence, and don't run out of memory.

So: A channel with buffer size 1, so long as it is only written to once and read from once, feels a lot like a Promise.

A variable you can only read once is a lot less useful than a variable you can read as many times as you want. Same goes for promises.

I don’t think I’ve seen a promise implementation that can’t handle multiple reads after the resolve for many years.

It would not take a lot of glue code to alter the contract to make that happen here.

that is a trivial memoizing wrapper on top of what GP described

If I could ask independently of the sentiment of this thread - I am genuinely curious: Why is marking the difference good? (sorry this is only tangential to the article)

The behavior and performance of asynchronous function depend on the behavior and performance of concurrent processes, making them more complex to reason about, test and be confident in their correctness and well-suitedness.

Cool use case. They're just called "non equi-joins" - because the join condition is an inequality. In general a join produces a row in the output table for each (left, right) pair of rows from the input tables that satisfies the join condition. It's just so common for joins to use a simple equality condition, where one or both sides is a unique id for its table, and people don't as often encounter joins where one input row can inform multiple output rows.