A modern programming language that makes developers happier.

kotlinlang

i'm curious about the async builder ---  in <https://spring.io/blog/2019/04/12/going-reactive-with-spring-coroutines-and-kotlin-flow|this> example (Parallel decomposition section) the tutorial uses
```async {
			client.get().uri("/userdetail1/${user.login}")
				.accept(APPLICATION_JSON)
				.awaitExchange().awaitBody&lt;UserDetail1&gt;()
		}```
am I wrong to think you could just do
```		val asyncDetail1 = client.get().uri("/userdetail1/${user.login}")
				.accept(APPLICATION_JSON)
		val asyncDetail2 = client.get().uri("/userdetail2/${user.login}")
				.accept(APPLICATION_JSON)
		UserWithDetails(user, asyncDetail1.awaitExchange().awaitBody&lt;UserDetail1&gt;(), asyncDetail2.awaitExchange().awaitBody&lt;UserDetail2&gt;())```
with the exact same result?

It's not the same, it's the whole point of this section. Wrapping in `async { .. }` makes the block of code asynchronous. This means that the next piece of code will run concurrently with this `async` block.

In short, using 2 `async` and _then_  awaiting both allows to make those 2 calls concurrently (and possibly in parallel on the right dispatcher)

<@UBXMWAA69> hmmm, but if client.get() returns a Mono (so it's async, too), shouldn't the call with no await work the same way? like if you throw that in a debugger, asyncDetail2 call wont wait until asyncDetail1 is fetched, no?

Oh my bad, I overlooked that you had removed the `awaitX` parts in the 2 calls

I'm assuming the goal is to remove usages of `Mono` at some point and migrate to coroutines, so there `client.get()` could instead be turned into suspending functions. It's kinda one step further towards the migration.

ah, I understand, but functionally it should be the same, right?

I'm not very familiar with how `Mono` and the rest of the reactive framework works, but there may also be a difference in how both handle errors. With structured concurrency, if one of the client calls fails, it cancels the other and throws. In particular if the _second_ call fails, the first will be canceled right away and the function overall will throw.

In the case of the pure `Mono` approach that you suggested, if we assume the first call succeeds in 5 seconds, but the second fails almost immediately, I believe you will still have to wait for the first call to complete before the second await can throw (but that's an assumption)

i'll try the fails example locally, I am curious about it. I will say kotlin's approach to asynchronous code is fantastic and feels good to use compared to java's

I also find coroutines awesome, and particularly nice on the use site :slightly_smiling_face: especially when compared to Java's futures, callbacks, and threads

yep! java's version reminds me of node's callback hell