i'm curious about the async builder --- in this example (Parallel decomposition section) the tutorial uses

async {
			client.get().uri("/userdetail1/${user.login}")
				.accept(APPLICATION_JSON)
				.awaitExchange().awaitBody<UserDetail1>()
		}

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<UserDetail1>(), asyncDetail2.awaitExchange().awaitBody<UserDetail2>())

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)

@Joffrey 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

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 see, very cool, thank you!

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

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