Imagine you're racing a Formula 1 car while wearing full fire-retardant gear, a neck brace, and a HANS device — and the other driver is in shorts and flip-flops. You might be a few percent slower, but you'll survive the crash. The question has always been: how much slower? This result says the answer might be single digits. The committed claim: a DEFLATE compression implementation written in Roc — a pure functional language with mandatory bounds checking, automatic reference counting, no unsafe escape hatch, and enforced purity in the type system — achieves a median slowdown of just 8.9% on AMD Ryzen 3900X and 2.6% on Apple M1 versus libdeflate, the gold-standard hand-tuned C implementation with architecture-specific SIMD. On certain inputs, the Roc version is 18% faster. This is not a toy benchmark; it uses the standard Silesia corpus across 144 benchmark configurations (12 compression levels × 12 files) and verifies byte-identical output. The architectural story matters. Roc achieves this through three key mechanisms: opportunistic mutation (what Koka calls 'Functional but In-Place'), which lets the compiler mutate values in-place when reference counts prove uniqueness; compile-time bounds-check hoisting, where a guard before a loop lets the optimizer delete per-iteration checks; and compile-time lookup table construction that eliminates runtime initialization costs. None of these require the programmer to reach for unsafe primitives — the compiler proves safety and then removes the guardrails it proved unnecessary. The ladder is honest and clearly stated. The author benchmarks against libdeflate directly on the Silesia corpus, acknowledges that C's performance ceiling is structurally higher (SIMD access, no bounds checks, no refcounting), and explicitly states that any per-input advantage Roc holds could be closed by C but not vice versa. The article also contextualizes against Lean 4's lean-zip (which beat Rust's minizoxide but couldn't touch libdeflate) and minizoxide itself. This is a three-rung ladder: Lean beats Rust, Roc nearly matches C, C remains the ceiling. The integrity picture is mixed but mostly honest. The Silesia corpus is a well-known community benchmark for compression, not a cherry-picked dataset. Byte-identical output verification eliminates the possibility of trading compression quality for speed. The benchmarks run on two architectures (ARM and x64), reducing platform-specific flukes. However, this is a single-author benchmark with no independent replication, no pre-registration, and the optimization work was done on the same M1 machine that shows the tightest gap (2.6%). The x64 numbers (8.9% median gap) are arguably the more conservative and representative result. The real contribution isn't the specific numbers — it's the demonstrated existence proof. Before this, nobody knew a pure FP language with mandatory memory safety, enforced purity, and no unsafe escape hatch could get within shouting distance of hand-tuned SIMD C on a performance-critical workload like compression. The author is appropriately cautious: this is one package, one domain, and Roc is pre-1.0. But the demonstrated possibility reprices the entire safety-performance conversation. The question shifts from 'how much performance do you sacrifice for safety?' to 'is single-digit percent overhead worth guaranteed memory safety, no side effects, deterministic cross-platform behavior, and supply-chain security?' The supply-chain security angle deserves attention. Roc's type system enforces purity at the package boundary — pure functions cannot perform I/O or access arbitrary memory, and packages don't support build scripts. The author pointedly notes that the Rust arrayref package was compromised via build scripts two months prior, and a Brotli RCE vulnerability from unchecked memory operations happened literally the day before publication. These aren't theoretical risks; they're the actual cost of the performance ceiling that C and Rust occupy.
