February 2, 2026
Fast server, faster flame war
My (very) fast zero-allocation webserver using OxCaml
Speed-demon OCaml server has Python refugees swooning and purists clutching pearls
TLDR: An OxCaml-based web server promises big speed by avoiding extra memory use. Comments split: Python-weary devs celebrate the move to safer code, while purists question if it’s still “functional,” and others demand type systems that expose hidden copies—making performance and programming philosophy the main battle.
A researcher just dropped httpz, a zero-allocation web server built with OxCaml—a souped‑up flavor of OCaml (a functional language) built for speed. Translation: it handles a whole web request without creating extra stuff in memory, so cleaning up is just returning from a function. Less trash for the garbage collector, more raw speed. He even swapped out his own site to test it, leaning on new “unboxed” numbers and stack‑only data to keep everything tight. If you’re curious about the memory magic, he points to Real World OCaml for background.
Then the comments lit up. Python veterans cheered, with one saying moving to a purely functional setup felt like a rebirth. Meanwhile, purists clutched pearls: “Does it look like functional programming anymore?” asked one skeptic, worried this speed run breaks the aesthetic of FP. The spiciest take? A rant that it’s a massive crime we still don’t have type systems that reveal hidden copies and allocations, blaming them for silent performance bugs. Jokes flew fast: memes about “callback soup” getting replaced by a no‑GC keto diet, and devs dubbing this OCaml on creatine. Verdict: hype vs purity, and everyone’s timing the benches while arguing about the soul of functional code.
Key Points
- •The article introduces “httpz,” a high-performance HTTP/1.1 webserver built with OxCaml to minimize heap allocations.
- •httpz uses OxCaml’s unboxed records (#{}) and int16# integers, enabling request handling on the call stack with minimal garbage collection.
- •The parser operates on a fixed 32KB bytes buffer representing HTTP request headers; POST body handling is noted but not covered.
- •Design choices contrast OCaml’s Bigarray/cstruct approach with a switch to bytes and unboxed types for speed and low allocation.
- •Unboxed records have special layouts that hinder standard introspection via the Obj module, demonstrated with utop examples.