When Abstractions Don't Scale: 5-Field Capture vs Haskell's 5-Tuple

When Abstractions Don’t Scale: 5-Field Capture vs Haskell’s 5-Tuple

Last time, we benchmarked a simple sum: foldl' (+) 0 [1..n] vs ~capture(\{ sum: 0 \}). Koru was 4.4x faster. Respectable, but Haskell defenders might argue “that’s just constant overhead, who cares?”

So we asked: what happens when we scale up the accumulator?

The Benchmark: 5-Field Statistics in One Pass

Computing sum, sum of squares, count, min, and max simultaneously. This is a REAL pattern - online statistics algorithms, streaming aggregations, financial calculations.

Haskell with foldl’ and 5-tuple

foldl' ((s, sq, c, mn, mx) x ->
    ( s + x
    , sq + x * x
    , c + 1
    , min mn x
    , max mx x
    )) (0, 0, 0, maxBound, minBound) [1..n]

Classic functional style. Strict fold, tuple accumulator, one pass through the data.

Koru with ~capture

~capture({ sum: 0, sum_sq: 0, count: 0, min_val: MAX, max_val: MIN })
| as s |> for(1..n+1)
    | each x |> captured {
        sum: s.sum + x,
        sum_sq: s.sum_sq + x * x,
        count: s.count + 1,
        min_val: if (x < s.min_val) x else s.min_val,
        max_val: if (x > s.max_val) x else s.max_val
      }
| captured stats |> print_stats(stats)

Same semantics: one pass, 5 fields updated atomically, pure dataflow.

Hand-Written Zig (Control)

var sum: i64 = 0;
var sum_sq: i64 = 0;
var count: i64 = 0;
var min_val: i64 = maxInt(i64);
var max_val: i64 = minInt(i64);

for (1..N + 1) |i| {
    const x: i64 = @intCast(i);
    sum += x;
    sum_sq += x * x;
    count += 1;
    if (x < min_val) min_val = x;
    if (x > max_val) max_val = x;
}

Five mutable variables, a loop, conditionals. The “obvious” imperative solution.

The Results

Running with N = 100,000,000 (100 million iterations), measured with Hyperfine:

Read that again. 1300x slower.

The simple sum was 4.4x slower. Adding 4 more fields made it 295x worse.

Why Did Haskell Fall Off a Cliff?

Here’s the subtle trap: foldl' only forces the accumulator to WHNF (Weak Head Normal Form). For a tuple, that means “it’s a 5-tuple” - but the fields inside aren’t evaluated!

So each iteration builds a thunk:

(s + x, sq + x*x, c + 1, min mn x, max mx x)

After 100 million iterations, you have 100 million nested thunks. The final show forces them all at once, causing a GC apocalypse.

Can We Fix The Tuple With Bang Patterns?

Yes! Force every field explicitly:

step (!s,!sq,!c,!mn,!mx) !x =
  let !s'  = s + x
      !sq' = sq + x*x
      ...
  in (s',sq',c',mn',mx')

Result: 145 ms - down from 63 seconds! But still 3x slower than Koru.

What About a Strict Data Type?

Even better:

{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE Strict #-}

data Stats = Stats !Int !Int !Int !Int !Int

foldl' ((Stats !s !sq !c !mn !mx) !x ->
    Stats (s + x) (sq + x * x) (c + 1) (min mn x) (max mx x)
    ) (Stats 0 0 0 maxBound minBound) [1..n]

Result: 77 ms - only 1.5x slower than Koru!

So the FULL comparison (Hyperfine, 5 runs):

The Hidden Lesson

Here’s what you need to know to get good Haskell performance:

1. Use foldl' not foldl (everyone knows this)
2. foldl' only forces to WHNF - tuple fields can still be lazy!
3. Add bang patterns to EVERY field, or…
4. Use a strict data type with ! annotations

Miss any of these? You get 3x to 1300x slower code. The “obvious” code - foldl' with a tuple - looks strict but isn’t.

With Koru, the obvious code IS the fast code:

~capture({ sum: 0, sum_sq: 0, count: 0, min_val: MAX, max_val: MIN })
| as s |> for(1..n) ...

There’s no “optimization dialect” to learn. No BangPatterns pragma. No strict field annotations. The abstraction compiles to optimal code BY DEFAULT.

Why Did Koru Stay Fast?

Koru’s ~capture compiles to this:

var s: __CaptureT = .{ .sum = 0, .sum_sq = 0, .count = 0, ... };
for (1..N) |i| {
    s = .{
        .sum = s.sum + x,
        .sum_sq = s.sum_sq + x * x,
        // ...
    };
}

That’s a stack-allocated struct being mutated in-place. No heap. No GC. No boxing. The struct assignment compiles to 5 register/stack operations.

The number of fields doesn’t matter. 1 field or 5 fields or 50 fields - it’s still stack allocation, still compiles to the same number of instructions per field.

The Scaling Story

Without strictness annotations, thunk accumulation scales CATASTROPHICALLY. With proper strictness, Haskell gets within 1.5x of native - respectable!

But here’s the key insight: Koru gives you strict-data-type performance with tuple-like syntax. You don’t have to choose between ergonomics and speed.

Why This Is A Big Deal

This isn’t about Haskell being slow. With the right incantations (BangPatterns, strict data types, careful field annotations), Haskell gets within 2x of native code.

The question is: why should you need incantations?

For 30 years, functional programmers have learned an “optimization dialect”:

• Use foldl' not foldl
• Add ! to strict fields
• Enable BangPatterns
• Use UNPACK pragmas
• Avoid tuple accumulators
• etc.

Each of these is knowledge you have to acquire. Each is a way the “obvious” code is wrong.

Koru says: the obvious code should be the fast code.

What You’re Actually Writing

Look at the Koru code again:

~capture({ sum: 0, count: 0 })
| as acc |> for(items)
    | each x |> captured { sum: acc.sum + x, count: acc.count + 1 }
| captured result |> use(result)

This is PURE DATAFLOW:

• acc is immutable - you never mutate it
• captured \{ ... \} returns a NEW state (like Haskell’s tuple return)
• State flows FORWARD through continuations
• No assignment operators, no mutation syntax

The semantics are Haskell. The performance is Zig.

The Abstraction Penalty

Here’s what the benchmark actually proves:

Haskell’s abstraction (tuple) has RUNTIME COST that scales with size.

Koru’s abstraction (~capture) has ZERO COST at any size.

This means:

• 5 fields? Zero overhead.
• 50 fields? Zero overhead.
• Nested captures inside loops inside conditionals? Zero overhead.

The abstraction compiles away COMPLETELY. Not “mostly.” Not “after warmup.” COMPLETELY.

The Real Innovation

Koru proves that functional semantics don’t require functional runtime.

Purity, immutability, explicit dataflow - these are DESIGN PATTERNS, not language features that require garbage collection.

You get:

• ✅ Haskell’s reasoning model (pure functions, explicit state)
• ✅ Haskell’s composability (continuations chain like monads)
• ✅ Zig’s performance (zero allocation, predictable latency)
• ✅ Zig’s control (you know exactly what code runs)

This isn’t “another way to write Zig.” This is Haskell’s dream realized without Haskell’s tradeoffs.

What This Means In Practice

If you’re doing streaming aggregation with multiple accumulators, the abstraction you choose MATTERS:

Haskell’s approach:

• Beautiful syntax
• Correctness guarantees
• Runtime overhead that scales with state size

Koru’s approach:

• Clear syntax (arguably clearer than tuple pattern matching)
• Same correctness guarantees (pure dataflow)
• Zero runtime overhead at any state size

The “zero-cost abstraction” claim isn’t marketing. It’s a compiler architecture decision. When your abstractions compile away COMPLETELY, scaling is free.

The Takeaway

Koru’s multi-field capture doesn’t just match hand-written Zig. It maintains that match as you scale up.

Haskell’s tuple fold is elegant, but the elegance has a price. And that price increases with every field you add.

For streaming computation, real-time aggregation, and any hot loop with complex state: zero-cost abstractions aren’t optional. They’re the difference between 0.04 seconds and 76 seconds.

That’s not an optimization. That’s a different class of solution.

A New Point In The Design Space

The 1300x number isn’t just a benchmark win. It’s PROOF that:

1. The abstraction penalty can be zero - not low, ZERO
2. Scaling is free - 5 fields or 500, same overhead (none)
3. Purity compiles to mutation - functional semantics, imperative performance
4. You don’t have to choose - correctness AND speed, not correctness OR speed

For decades, “functional programming” meant accepting runtime overhead as the price of correctness. Koru demonstrates that this tradeoff was never fundamental - it was an implementation choice.

Functional semantics. Systems performance. No compromise.

That’s what we’re building.