DEV Community: Damián Rafael Lattenero

Stop wiring async calls manually

Damián Rafael Lattenero — Mon, 30 Mar 2026 01:06:48 +0000

If you’ve written non-trivial coroutine code, you’ve probably built something like this:

multiple async calls
some run in parallel
some depend on earlier results
everything gets glued together manually

And at some point… it starts to feel messy.

The real problems (not the obvious ones)

Raw coroutines are great, but orchestration has hidden costs:

Dependencies are implicit
Phases are invisible
You manually wire values between steps
Swapping values can still compile if types match

Example:

val user = async { fetchUser() }
val cart = async { fetchCart() }
val promos = async { fetchPromos() }

val result = combine(
    user.await(),
    promos.await(), // swapped accidentally
    cart.await()
)

👉 This compiles.
👉 And now you have a bug.

What I wanted instead

I wanted something where:

parallel work is obvious
dependencies are explicit
phases are visible
and if it compiles, the wiring is correct

Enter KAP

val checkout: CheckoutResult = Async {
    kap(::CheckoutResult)
        .with { fetchUser() }
        .with { fetchCart() }
        .with { fetchPromos() }
        .with { fetchInventory() }

        .then { validateStock() }

        .with { calcShipping() }
        .with { calcTax() }
        .with { calcDiscounts() }

        .andThen { partial ->
            kap(::FinalCheckout)
                .with { reservePayment(partial) }
                .with { applyLoyaltyPoints(partial) }
        }

        .with { generateConfirmation() }
        .with { sendEmail() }
}

👉 13 calls
👉 6 phases
👉 no manual wiring

The dependency graph is the code.

The mental model (it’s simpler than it looks)

You only need three things:

You write	What it means
`.with { }`	runs in parallel with others
`.then { }`	waits for all previous
`.andThen { ctx -> }`	next step using previous result

That’s it.

Why this matters

1. No more invisible phases

With coroutines:

phases exist
but you don’t see them

With KAP:

phases are structural

2. No more manual wiring

You don’t pass values around manually anymore.

No more:

val ctx = ...
val enriched = ...

3. Compile-time safety

This is the key:

If it compiles, your async wiring is correct.

You literally can’t swap values accidentally.

4. Code reads like execution

Instead of:

“how is this executed?”

You read:

“this runs together → then this → then this depends on that”

Performance?

Same as raw coroutines.

no reflection
no runtime code generation
zero overhead

Benchmarks: ~identical execution time.

When this is useful

This shines when you have:

multi-service orchestration
dashboards
checkout flows
aggregation pipelines
anything with parallel + dependent steps

When you don’t need it

If you have:

1–2 coroutine calls
no dependency structure

👉 stick with plain coroutines

Final thought

Coroutines solve concurrency.

KAP solves orchestration.

I applied Haskell's Applicative Functors to Kotlin Coroutines. Here's what happened.

Damián Rafael Lattenero — Mon, 23 Mar 2026 20:46:12 +0000

How currying, functors, applicative functors and monads from Haskell led me to build a parallel orchestration library for Kotlin coroutines with zero overhead.
tags: kotlin, functionalprogramming, haskell, coroutines

If you know Haskell, you already know this library

In Haskell, combining independent IO actions looks like this:

mkDashboard <$> fetchUser <*> fetchCart <*> fetchPromos

Three independent effects. The runtime can execute them however it wants — including in parallel. The structure tells you: these don't depend on each other.

When one result depends on another, you switch to monadic bind:

do
  ctx <- mkContext <$> fetchProfile <*> fetchPrefs <*> fetchTier
  mkDashboard <$> fetchRecs ctx <*> fetchPromos ctx <*> fetchTrending ctx

Phase 1 is applicative (parallel). Phase 2 is monadic (depends on ctx). The code shape is the dependency graph.

I looked at Kotlin coroutines and saw the same problem: you need to orchestrate parallel calls with sequential barriers, but async/await gives you no way to express this distinction. So I built KAP — Kotlin Applicative Parallelism. The Haskell pattern, natively expressed in Kotlin coroutines.

Here's the same thing in KAP:

val dashboard = Async {
    lift3(::UserContext)
        .ap { fetchProfile(userId) }       // ┐ phase 1: applicative (parallel)
        .ap { fetchPrefs(userId) }         // │
        .ap { fetchTier(userId) }          // ┘
    .flatMap { ctx ->                      // >>= monadic bind (barrier)
        lift3(::Dashboard)
            .ap { fetchRecs(ctx) }         // ┐ phase 2: applicative (parallel)
            .ap { fetchPromos(ctx) }       // │
            .ap { fetchTrending(ctx) }     // ┘
    }
}

If you know Haskell, you can read this immediately: lift3(f).ap.ap.ap is f <$> a <*> b <*> c. .flatMap is >>=. That's the whole mapping.

Haskell                          KAP (Kotlin)
─────────                        ────────────
f <$> a <*> b <*> c          →  lift3(f).ap{a}.ap{b}.ap{c}
ma >>= \x -> mb x            →  computation.flatMap { x -> ... }
pure x                        →  Computation.pure(x)
fmap f ma                     →  computation.map { f(it) }

If you're a Kotlin developer who's never touched Haskell — don't worry. The rest of this post explains everything with raw coroutines comparisons. You don't need to know Haskell to use KAP. But if you do, you'll feel right at home.

The problem: 11 microservice calls, 5 phases

You have a checkout flow. 11 services. Some can run in parallel, others depend on earlier results. Here's what Kotlin gives you today:

Raw coroutines:

val checkout = coroutineScope {
    val dUser      = async { fetchUser(userId) }
    val dCart       = async { fetchCart(userId) }
    val dPromos    = async { fetchPromos(userId) }
    val dInventory = async { fetchInventory(userId) }
    val user       = dUser.await()
    val cart        = dCart.await()
    val promos     = dPromos.await()
    val inventory  = dInventory.await()

    val stock = validateStock(inventory)    // barrier — but you can't SEE it

    val dShipping  = async { calcShipping(cart) }
    val dTax       = async { calcTax(cart) }
    val dDiscounts = async { calcDiscounts(promos) }
    val shipping   = dShipping.await()
    val tax        = dTax.await()
    val discounts  = dDiscounts.await()

    val payment = reservePayment(user, cart)  // barrier — also invisible

    val dConfirmation = async { generateConfirmation(payment) }
    val dEmail        = async { sendReceiptEmail(user) }

    CheckoutResult(user, cart, promos, inventory, stock,
                   shipping, tax, discounts, payment,
                   dConfirmation.await(), dEmail.await())
}

30+ lines. 8 shuttle variables. Phase boundaries invisible without comments. Move one await() above its async and you silently serialize — the compiler won't warn.

KAP:

val checkout = Async {
    lift11(::CheckoutResult)
        .ap { fetchUser(userId) }          // ┐
        .ap { fetchCart(userId) }           // ├─ phase 1: parallel
        .ap { fetchPromos(userId) }        // │
        .ap { fetchInventory(userId) }     // ┘
        .followedBy { validateStock() }    // ── phase 2: barrier
        .ap { calcShipping() }            // ┐
        .ap { calcTax() }                 // ├─ phase 3: parallel
        .ap { calcDiscounts() }           // ┘
        .followedBy { reservePayment() }  // ── phase 4: barrier
        .ap { generateConfirmation() }    // ┐ phase 5: parallel
        .ap { sendReceiptEmail() }        // ┘
}

12 lines. All val. No nulls. Phases visible. Swap any two .ap lines of different types — compiler error. Same wall-clock time: 130ms virtual time (vs 460ms sequential), verified with runTest.

How it works: currying + three primitives

Currying is what makes lift + ap possible. In Haskell, all functions are curried by default. In Kotlin, lift11(::CheckoutResult) curries an 11-argument constructor into a chain where each .ap fills one slot. This is why swapping two .ap lines is a compiler error — each slot expects a specific type at compile time.

The entire library is built on three primitives:

Primitive	Haskell equivalent	What it does
`.ap { }`	`<*>`	Launch in parallel with everything above
`.followedBy { }`	`*>` (with barrier)	Wait for everything above, then continue
`.flatMap { ctx -> }`	`>>=`	Wait, pass the result, then continue

And lift works with any function — not just constructors:

// A data class constructor IS a function:
//   ::Greeting  has type  (String, String) -> Greeting
val g = Async { lift2(::Greeting).ap { fetchName() }.ap { "hello" } }

// A regular function:
fun buildSummary(name: String, items: Int) = "$name has $items items"
val s = Async { lift2(::buildSummary).ap { fetchName() }.ap { 5 } }

// A lambda:
val greet: (String, Int) -> String = { name, age -> "Hi $name, you're $age" }
val r = Async { lift2(greet).ap { fetchName() }.ap { fetchAge() } }

When Phase 2 depends on Phase 1: `flatMap`

Raw coroutines — three separate coroutineScope blocks, manual variable threading:

val ctx = coroutineScope {
    val dProfile = async { fetchProfile(userId) }
    val dPrefs   = async { fetchPreferences(userId) }
    val dTier    = async { fetchLoyaltyTier(userId) }
    UserContext(dProfile.await(), dPrefs.await(), dTier.await())
}
val enriched = coroutineScope {
    val dRecs     = async { fetchRecommendations(ctx.profile) }
    val dPromos   = async { fetchPromotions(ctx.tier) }
    val dTrending = async { fetchTrending(ctx.prefs) }
    val dHistory  = async { fetchHistory(ctx.profile) }
    EnrichedContent(dRecs.await(), dPromos.await(), dTrending.await(), dHistory.await())
}
val dashboard = coroutineScope {
    val dLayout = async { renderLayout(ctx, enriched) }
    val dTrack  = async { trackAnalytics(ctx, enriched) }
    FinalDashboard(dLayout.await(), dTrack.await())
}

Three scopes. Manual ctx and enriched threading. The dependency between phases is invisible in the code structure.

KAP — single expression, dependencies are the structure:

val dashboard: FinalDashboard = Async {
    lift3(::UserContext)
        .ap { fetchProfile(userId) }         // ┐
        .ap { fetchPreferences(userId) }     // ├─ phase 1 (parallel)
        .ap { fetchLoyaltyTier(userId) }     // ┘
    .flatMap { ctx ->                        // ── barrier: phase 2 NEEDS ctx
        lift4(::EnrichedContent)
            .ap { fetchRecommendations(ctx.profile) }  // ┐
            .ap { fetchPromotions(ctx.tier) }           // ├─ phase 2 (parallel)
            .ap { fetchTrending(ctx.prefs) }            // │
            .ap { fetchHistory(ctx.profile) }           // ┘
        .flatMap { enriched ->                          // ── barrier
            lift2(::FinalDashboard)
                .ap { renderLayout(ctx, enriched) }     // ┐ phase 3
                .ap { trackAnalytics(ctx, enriched) }   // ┘
        }
    }
}

t=0ms   ─── fetchProfile ──────┐
t=0ms   ─── fetchPreferences ──├─ phase 1 (parallel, all 3)
t=0ms   ─── fetchLoyaltyTier ──┘
t=50ms  ─── flatMap { ctx -> }  ── barrier, ctx available
t=50ms  ─── fetchRecommendations ──┐
t=50ms  ─── fetchPromotions ───────├─ phase 2 (parallel, all 4)
t=50ms  ─── fetchTrending ─────────┤
t=50ms  ─── fetchHistory ──────────┘
t=90ms  ─── flatMap { enriched -> } ── barrier
t=90ms  ─── renderLayout ──┐
t=90ms  ─── trackAnalytics ┘─ phase 3 (parallel)
t=115ms ─── FinalDashboard ready

All `val`, no `null`, no `!!`

Raw coroutines force you into mutable nullable variables:

data class CheckoutView(
    val user: UserProfile,
    val cart: ShoppingCart,
    val promos: PromotionBundle,
    val shipping: ShippingQuote,
    val tax: TaxBreakdown,
)

var user: UserProfile? = null
var cart: ShoppingCart? = null
var promos: PromotionBundle? = null
var shipping: ShippingQuote? = null
var tax: TaxBreakdown? = null
coroutineScope {
    launch { user = fetchUser() }
    launch { cart = fetchCart() }
    launch { promos = fetchPromos() }
    launch { shipping = calcShipping() }
    launch { tax = calcTax() }
}
val view = CheckoutView(user!!, cart!!, promos!!, shipping!!, tax!!)
// 5 vars. 5 nulls. 5 bang-bangs. One forgotten launch → NPE at runtime.

KAP — the constructor receives everything at once. Every field is val. Nothing is ever null:

val view: CheckoutView = Async {
    lift5(::CheckoutView)
        .ap { fetchUser() }
        .ap { fetchCart() }
        .ap { fetchPromos() }
        .ap { calcShipping() }
        .ap { calcTax() }
}
// Constructor called once with all 5 values. Nothing was ever null.

At 11 fields it's 11 var, 11 ?, 11 !!. KAP stays flat.

`Computation` is a description, not an execution

Like Haskell's IO, Computation is a value that describes work — it doesn't perform it. Nothing runs until Async {}:

// This builds a plan — nothing runs yet
val plan: Computation<Dashboard> = lift3(::Dashboard)
    .ap { fetchUser() }     // NOT executed
    .ap { fetchCart() }     // NOT executed
    .ap { fetchPromos() }   // NOT executed

// NOW it runs — all three in parallel
val result: Dashboard = Async { plan }
println(result) // Dashboard(user=Alice, cart=3 items, promos=SAVE20)

You can store computation graphs, pass them around, compose them — all without triggering side effects. This is fundamentally different from async {}, which starts immediately.

What only KAP can do

These features don't have a clean equivalent in raw coroutines or Arrow.

Partial failure tolerance

Raw coroutines: coroutineScope cancels ALL siblings when one fails. You can't collect partial results.

KAP: .settled() wraps individual branches in Result so one failure doesn't cancel siblings:

val dashboard = Async {
    lift3 { user: Result<String>, cart: String, config: String ->
        Dashboard(user.getOrDefault("anonymous"), cart, config)
    }
        .ap(Computation { fetchUserMayFail() }.settled())
        .ap { fetchCart() }     // keeps running even if user fails
        .ap { fetchConfig() }   // keeps running even if user fails
}

Timeout with parallel fallback

Raw coroutines: wait for the timeout, then start the fallback (sequential).

KAP: start both at t=0, return whichever wins (parallel):

val result = Async {
    Computation { fetchFromPrimary() }
        .timeoutRace(100.milliseconds, Computation { fetchFromFallback() })
}
// JMH: KAP 30.34ms vs raw coroutines 180.55ms — 6x faster

Quorum consensus

Raw coroutines: no primitive. You'd build it yourself with select and manual cancellation.

KAP: return the first 2 successes out of 3 replicas, cancel the rest:

val quorum: List<String> = Async {
    raceQuorum(
        required = 2,
        Computation { fetchReplicaA() },
        Computation { fetchReplicaB() },
        Computation { fetchReplicaC() },
    )
}

Per-branch resilience

Raw coroutines: 30+ lines of nested try/catch with manual backoff math per branch.

KAP: each .ap branch carries its own timeout, retry, circuit breaker, or fallback:

val breaker = CircuitBreaker(maxFailures = 5, resetTimeout = 30.seconds)
val retryPolicy = Schedule.recurs<Throwable>(3) and Schedule.exponential(100.milliseconds)

val result = Async {
    lift3(::Dashboard)
        .ap(Computation { fetchUser() }
            .withCircuitBreaker(breaker)
            .retry(retryPolicy)
            .recover { "cached-user" })
        .ap(Computation { fetchFromSlowApi() }
            .timeoutRace(100.milliseconds, Computation { fetchFromCache() }))
        .ap { fetchPromos() }
}

Parallel validation — collect every error

Raw coroutines: impossible. Structured concurrency cancels all siblings when one throws.

Arrow: zipOrAccumulate handles it, but maxes out at 9 arguments.

KAP: scales to 22, all validators run in parallel, all errors accumulated:

val registration: Either<NonEmptyList<RegError>, User> = Async {
    liftV4<RegError, ValidName, ValidEmail, ValidAge, ValidUsername, User>(::User)
        .apV { validateName("Alice") }       // ┐ all 4 in parallel
        .apV { validateEmail("alice@ex.com") } // │ errors accumulated
        .apV { validateAge(25) }              // │ (not short-circuited)
        .apV { checkUsername("alice") }       // ┘
}
// 3 fail? → Left(NonEmptyList(NameTooShort, InvalidEmail, AgeTooLow))
// All pass? → Right(User(...))

Chain phases with accumulate — validate identity first, then check business rules:

val result: Either<NonEmptyList<RegError>, Registration> = Async {
    accumulate {
        val identity = zipV(
            { validateName("Alice") },
            { validateEmail("alice@example.com") },
            { validateAge(25) },
        ) { name, email, age -> Identity(name, email, age) }
            .bindV()

        val cleared = zipV(
            { checkNotBlacklisted(identity) },
            { checkUsernameAvailable(identity.email.value) },
        ) { a, b -> Clearance(a, b) }
            .bindV()

        Registration(identity, cleared)
    }
}

Benchmarks: 119 JMH tests

Dimension	Raw Coroutines	Arrow	KAP
Framework overhead (arity 3)	<0.01ms	0.02ms	<0.01ms
Framework overhead (arity 9)	<0.01ms	0.03ms	<0.01ms
Simple parallel (5 x 50ms)	50.27ms	50.33ms	50.31ms
Multi-phase (9 calls, 4 phases)	180.85ms	181.06ms	180.98ms
Validation (4 x 40ms)	N/A	40.32ms	40.28ms
Retry (3 attempts w/ backoff)	120.70ms	—	30.21ms
timeoutRace (primary wins)	180.55ms	—	30.34ms
Max validation arity	—	9	22
Compile-time arg safety	No	No	Yes
Quorum race (N-of-M)	Manual	No	Yes

KAP matches raw coroutines in latency and overhead. Where it pulls ahead: timeoutRace (parallel fallback — 6x faster), retry with Schedule (declarative vs manual loops — 4x), and race (auto-cancel loser).

Live benchmark dashboard — tracked on every push to master.

Getting started

Three modules, pick what you need:

dependencies {
    // Core — the only required module (zero deps beyond coroutines)
    implementation("io.github.damian-rafael-lattenero:kap-core:2.1.0")

    // Optional: resilience (Schedule, CircuitBreaker, Resource, bracket)
    implementation("io.github.damian-rafael-lattenero:kap-resilience:2.1.0")

    // Optional: Arrow integration (validated DSL, Either/Nel, raceEither)
    implementation("io.github.damian-rafael-lattenero:kap-arrow:2.1.0")
}

906 tests across 61 suites. 119 JMH benchmarks. Kotlin Multiplatform (JVM / JS / Native). 7 runnable examples. Algebraic laws (Functor, Applicative, Monad) property-tested with Kotest.

All code examples in this post are compilable — they live in examples/readme-examples/ and run on every CI push.

GitHub: github.com/damian-rafael-lattenero/coroutines-applicatives