I’ve caught myself do something like this: ```retu...

# arrow

[Stylianos Gakis]

I’ve caught myself do something like this:

return either<Error, Unit> {
  parZip(
    { someComputation().toEither() },
    { someComputation().toEither() },
  ) { one, two ->
    one.bind()
    two.bind()
  }
}

When I simply want two things to run in parallel, get the structured concurrency guarantees of cancelling each other if one fails, and simply get an answer of it both succeeded or not.
I feel like the parZip is kinda of redundant since I’m not combining the two results in any way, and could even move the bind() inside the two lambdas and then the trailing lambda is useless.
Is there some other part of the arrow API that I’m missing, or might as well go with doing the async();async();awaitAll() dance myself?

[simon.vergauwen]

Hey @Stylianos Gakis,

I've encountered this a couple of times myself. I've been thinking if we can expose a parZip without the lambda in Arrow 2.0, or a lambda that returns Pair<A, B>? 🤔

Since we're reducing the API surface in many places, the resulting binary would still be smaller.

When I simply want two things to run in parallel, get the structured concurrency guarantees of cancelling each other if one fails, and simply get an answer of it both succeeded or not.

Should the first task cancel the second one if it results in Either.Left? Then I think you want:

either<Error, Unit> {
  parZip(
   { someComputation().bind() },
   { someComputation().bind() }
  ) { _,_ -> }
}

Assuming someComputation returns Effect. If not then toEither().bind().

With the proposed overload for Arrow 2.0 it could become:

either<Error, Unit> {
  parZip(
   { someComputation().bind() },
   { someComputation().bind() }
  ) { _,_ -> }
}

[Stylianos Gakis]

Yeah that’s true, as I wrote it above it would not cancel each other since my toEither was in fact turning the failure of someComputation into a result type aka not throw, so it was wrong, thanks for pointing this out!
Yes I agree with the new function, for now I’ll do the { _, _ -> } solution. Thanks for the help!

[simon.vergauwen]

My pleasure, thanks for the feedback! Lets try improving this for 2.0 🙌