Owning the stack

The case for Cruft implementing its own parser, engines, codecs, crypto, and databases rather than pulling them from a package registry. It lays out the bets on trust, binary size, and speed, and names the two dependencies that stay, Cranelift for JIT code generation and libc for the operating-system ABI.

Compared to most runtimes, Cruft is substantially more self-contained. A large share of what a runtime does is often delegated to third-party libraries pulled from a package registry, with the runtime as the glue around them. Cruft takes the opposite position: it owns its entire stack. The parser, bytecode compiler, interpreter, garbage collector, JIT admission, TLS, crypto, the HTTP and HTTP/2 codecs, the SQLite and Postgres engines, the compression codecs, the Unicode tables, and even the small utility data structures most projects vendor without thinking are all crates inside Cruft's own workspace, not dependencies from crates.io.

Third-party code is the exception. It is admitted only where implementing the equivalent would be a large project with no correctness or soundness benefit, or as a temporary stop-gap while the matching Cruft component matures. The dependency surface page is the full inventory; this page is the reasoning behind it.

Owning the stack is four bets at once: on trust, on size, on speed, and on the value of the experiment itself.

Provenance and trust

A runtime's job is to run code, and increasingly to contain code it does not trust. A runtime built on a deep tree of unaudited transitive dependencies cannot make that claim credibly. Every crate it pulls in is ambient authority at build time and a trust assumption at run time, and the tree is usually too large for any one team to have read.

Owning the stack collapses that tree. The code that runs your code is code Cruft maintains and can account for. No registry fetch can change what ships, no transitive dependency can be compromised upstream and pulled into a build, and there is no surface the project cannot point to and explain. Bundling only code the project controls is the strongest available form of knowing exactly what is in the binary, and for a runtime whose security model rests on isolation and capabilities, that provenance is part of the security model itself.

Binary size

A general-purpose library is built to serve every caller. It carries configuration, feature flags, format variants, and edge cases that any single consumer will never touch, and a runtime that vendors dozens of them pays for all of it in binary size.

Owning a dependency means implementing only the slice Cruft actually uses. The compression crate covers the DEFLATE and gzip paths the runtime needs, not a general compression toolkit. The base-N crate encodes the alphabets the platform exposes, not every encoding in use anywhere. Each owned component is scoped to its one consumer, so the binary carries what the runtime runs and nothing shipped just in case. Across roughly sixty-five owned components that difference compounds into a materially smaller binary than the same runtime assembled from full-surface libraries would produce.

Speed and efficiency

Co-owning a component with the engine that calls it removes the impedance between them. The data structures are shaped for the access patterns Exegesis actually has, the codecs hand bytes to the exact buffer types the runtime already uses, and there is no adapter layer translating between a library's general interface and the engine's specific needs. A dependency designed for one caller can make assumptions a public library cannot, and those assumptions are where the efficiency comes from.

A deliberate experiment

Beyond the practical arguments, owning the stack is a bet worth making on its own terms. How small, how coherent, and how auditable does a runtime become when one team owns every layer from the parser to the socket, under a single set of conventions, with no seams where a vendored library's assumptions meet the engine's? Cruft is that question run at full scale. The result is not only the binary that comes out of it but what building it reveals: which dependencies were ever necessary, and which were habit.

Where the line falls

The bar for vendoring is high, and two things currently sit above it.

Cranelift, the JIT backend. LeJIT, Cruft's baseline JIT, owns the entire path down to code generation: which functions are admitted, what each specialization is allowed to assume, the hidden-class shapes it builds on, on-stack replacement, and deoptimization. It hands Cranelift a low-level IR and lets Cranelift emit machine code for the host architecture. This is a necessary dependency at LeJIT's current stage. An optimizing code generator with correct register allocation across several architectures is a multi-year effort, and its benefit for the concerns Cruft is actually testing (soundness, isolation, spec conformance) is close to nil, because Exegesis is the semantic source of truth and the JIT only has to match it. Cranelift is a focused backend that does exactly that job while LeJIT matures. See LeJIT for how the two fit together.

libc, the operating-system ABI. libc is the binding to the platform's C ABI, the syscall surface every native program ultimately calls. It is essentially the name of the operating system's own interface, and there is nothing to own beneath it.

Both are the shape of the principle at work. Neither is an exception to it. Vendor where the code is genuinely someone else's to own, such as the operating system, or where owning it would cost years for a benefit Cruft does not need, such as an optimizing code generator. Own everything else. As components like LeJIT mature, the line can move, and the direction it moves is inward.