Case study

ReactVision: cutting memory in an AR/VR rendering engine

“ReactVision is adopting Eskiu selectively to replace memory-sensitive C++ components in its AR/VR rendering engine with explicit, auditable native modules, while preserving C ABI interoperability with the existing stack.” ≈85% less memory in the rendering modules migrated to Eskiu.

The setup

ReactVision builds ViroCore, the native AR/VR rendering engine behind @reactvision/react-viro on iOS, Android, Meta Quest, and visionOS. It is a large, long-lived C++ codebase, on the order of 2,200+ files and ~23 MB of engine source, split across the parts you'd expect of a real-time renderer:

Subsystem	Scale
Renderer	~800 files
Physics	~480 files
Scene graph	~110 files
Image / texture, materials, lighting, text, particles	the rest

It ships to phones and headsets, where memory is the scarce resource: every texture buffer, scene-graph node, and per-frame allocation counts. The hot, memory-sensitive paths (image and texture preprocessing, the scene graph, physics) are exactly the kind of native code where how you allocate decides the footprint.

Why Eskiu fit

The team didn't want to rewrite the engine, and didn't want to trade C++'s control for a language with a garbage collector or a heavy runtime. Eskiu's shape matched the constraints:

Native, no runtime. Compiles to native code through LLVM, with no collector and nothing to embed, so the binary footprint stays predictable.
Memory you account for. alloc<T>(N) / free(ptr) live in the source. A migrated component's allocation pattern is explicit and auditable, not hidden behind a framework.
C ABI in and out. Eskiu speaks the C ABI directly and links as a plain native object. A module drops into the existing C++ engine, called from it and calling back into it, without rewriting the host.
Modern where it helps. Sum types with match, async/await, templates: current-language ergonomics without giving up the systems layer.

The approach

Selective, not a rewrite: take one memory-sensitive C++ component, re-implement it as an explicit Eskiu module, and link it in over the C ABI. The surrounding engine doesn't change; it sees the same symbols. Each migrated module is small enough to audit and measure on its own, so the footprint win is attributable. On the modules moved so far: ≈85% less memory.

The same language in the cloud

The other end of the stack validated the same toolchain. Eduardo's INE credential-QR decoder, a personal side project, a real image-plus-crypto pipeline (QR extraction, then multi-round AES-256-CBC + RSA-8192), was reimplemented in Eskiu and is served as an HTTP API. On the cryptographic pipeline it runs 2.5× faster than the reference C implementation, on a stack built entirely from Eskiu's standard library (<http>, <json>, <base64>, threading), with no external framework.

So the same language that boots a bare-metal ARM64 kernel, and that drops a memory-tight module into a C++ rendering engine, also runs a service in the cloud. One language across the stack, used where it pays off.