Rust for document engines: safety boundaries and real benchmarks

Document engines parse complex, often untrusted input and manage substantial memory during conversion and layout. Rust's ownership and borrowing rules can prevent many memory safety errors in safe code, while its type system can help express internal invariants. Those benefits should be tied to concrete implementation areas rather than used as a blanket security claim. Logic errors, excessive resource use, incorrect calculations, and faulty format interpretation remain possible. Review where unsafe code, native libraries, and foreign interfaces are used, because their obligations are not removed simply by calling them from a Rust application.

A malformed or highly compressed file can consume CPU, memory, or disk without exploiting a memory corruption bug. Set limits for archive expansion, object counts, nesting depth, image dimensions, execution time, and temporary storage as appropriate to supported formats. Make failure behavior explicit and preserve a useful diagnostic without dumping sensitive document content. Test cancellation and partial output cleanup. Use fuzzing and representative malformed samples to exercise parser boundaries, then track regressions through releases. Memory safety supports this work, but it does not define the product's accepted workloads or resource budgets.

Benchmark startup, parsing, layout, conversion, memory peaks, and throughput with the actual document corpus and target hardware. Compare equivalent outputs and correctness requirements; a faster result that omits content is not an improvement. Investigate profiling evidence before attributing speed to a language choice. Review build reproducibility, dependency updates, supported platforms, debugging tools, and available team skills. Rust can integrate through several interface styles, but the chosen boundary should match the application's deployment and failure model. Include the cost of maintaining bindings and platform packages in the engineering decision.