A modern programming language that makes developers happier.

kotlinlang

Hei.
```either {
    val (value1, value2) = parTupleN(
        suspend { someMethodReturningEither() },
        suspend { someMethodReturningEither() }
    )
    .right()
    .flatMap { (first, second) -&gt; first.mproduct { second } }
    .bind()

    val (value1, value2) = parTupleN(
        suspend { someMethodReturningEither().bind() },
        suspend { someMethodReturningEither().bind() }
    )
}```
Is there a difference between the two in terms of how parallelism will be done ?
This question is because how I was used to do `parTupledN` with `IO`.
There the results were always flatMapped and used to give `IO&lt;Tuple2&lt;A, B&gt;&gt;`

We have replaced IO for suspend which allows you to use inline functions from the data type as co-pure and therefore nest suspend effects like in this case. This can be further simplified if you bind also instead of using flatMap on Either.

IO will be deprecated in the next release and in the following only the fx Coroutines lib with suspend support will remain for IO

Sorry, I forgot to mention, this code **uses** `arrow-fx-coroutines`

So you mean :
```val (value1, value2) = parTupleN(
        suspend { someMethodReturningEither().bind() },
        suspend { someMethodReturningEither().bind() }
    )```
is exactly same as
```val (value1, value2) = parTupleN(
        suspend { someMethodReturningEither() },
        suspend { someMethodReturningEither() }
    )
    .right()
    .flatMap { (first, second) -&gt; first.mproduct { second } }
    .bind()```
with no change one how these methods will be executed with coroutines ?

Right, so the flatMap after right() can also be a bind I believe. If you have a compiling example I can try to rewrite it if it's not clear. Essentially if you are on an either block you don't need to use flatMap, map or any method of the Functor hierarchy, just invoke or in this case bind (all monad operators but invoke will be deprecated )

Also you should not need mproduct there if you use bind. We are enabling so you never have to chain functions like that since invoke removed the need for it

I understand. So just to confirm :
```val (value1, value2) = parTupleN(
        suspend { someMethodReturningEither().bind() },
        suspend { someMethodReturningEither().bind() }
    )```
Is much simpler approach than the other one right ?

Also flatMap will be gone ? :cry:

Yes, I can make a gist snippet very fast.

Yes is simpler, no, flatMap and those are still there but they're not as useful when you are in an either block since those allow imperative syntax over either values simply invoking them. Gives you the right value or short circuits on left

Yes. thank you so much :slightly_smiling_face:
I actually like to do function changes when there are 2-3 right biased operations, but if it grows, I convert it to `either` block, as it is less code, no pyramid and neat

I'm speaking on Friday at Javalove conf on how computation blocks are built and how people can build their own. Running on this example for monad bind and showing how it's implemented in arrow and 1.0 actually over Either in case you are interested how this is built and what you can do with blocks to remove boilerplate and increase performance