<div dir="ltr">It seems like for most people, input order isn't that important for concurrent work, and concurrent results being in non-deterministic order is often expected.<div><br></div><div>If mapConcurrent() just respect output encounter order:</div><div><br></div><div>It'll be able to achieve <b>higher throughput</b> if an early task is slow, For example, with concurrency=2, and if the first task takes 10 minutes to run, mapConcurrent() would only be able to process 2 tasks within the first 10 minutes; whereas with encounter order, the first task being slow doesn't block the 3rd - 100th elements from being processed and output.</div><div><br></div><div>mapConcurrent() can be used to implement useful concurrent semantics, for example to <b>support race</b> semantics. Imagine if I need to send request to 10 candidate backends and take whichever that succeeds first, I'd be able to do:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>backends.stream()</div><div>    .gather(mapConcurrent(</div><div>        backend -> {</div><div>          try {</div><div>            return backend.fetchOrder();</div><div>           } catch (RpcException e) {</div><div>             return null; // failed to fetch but not fatal</div><div>           }</div><div>        })</div><div>        .filter(Objects::notNull)</div><div>        .findFirst(); // first success then cancel the rest</div></blockquote><div><br></div><div>Cheers,</div><div><br></div></div>