Oliver Edis

Meet Eskiu, Our Systems Language That Saved ViroCore's Memory Consumption by up to 85%

Meet Eskiu thumbnail: ReactVision Labs branding for the Eskiu systems language announcement

When people think about ReactVision, they usually think about the parts they touch. ViroReact in their codebase, Studio in their browser, Platform powering things like Cloud and Geospatial Anchors. But sitting right at the heart of our stack, underneath ViroReact, is something most developers never see: ViroCore.

Today I want to introduce you to a piece of technology that's been quietly changing how ViroCore works. Its name is Eskiu.

ViroCore is where the magic happens

ViroCore is our native rendering engine. When you write a scene in ViroReact, or build one visually in Studio, it's ViroCore that actually draws it. Lighting, materials, physics, video, AR tracking, passthrough on a headset. All of that lives in ViroCore, and it's what lets one codebase run natively on iOS, Android, Meta Quest, visionOS and now the web.

In other words, if ViroReact is the promise of "write once, run anywhere", ViroCore is the bit that has to keep that promise.

More platforms means doing more with less

With ViroReact 3.0 we added visionOS and Web AR, and we're not stopping there. We're increasingly looking at devices where native AR frameworks simply don't exist, including custom hardware.

That changes the brief. On a flagship phone you can get away with a fair bit. On a lightweight headset, a pair of glasses or an embedded device, every megabyte counts. If ViroCore was going to follow ReactVision onto all of those platforms, it needed to get a lot leaner and a lot more portable.

Meet Eskiu

Eskiu is ReactVision's own systems language. It was created by our Technical Lead, Eduardo Dorantes, and it now ships in production inside ViroCore.

The simplest way to describe it: the power of C with the immediacy of a scripting language. (And yes, like our logo, its mascot is a cat.)

What it is and how it works

Eskiu compiles to native code through LLVM, so it runs as fast as you'd expect from a systems language. But you can also run a file directly with eskiuc run file.esk, just like a script, which makes iterating on it far quicker.

A few of the things that make it tick:

  • Explicit memory, no garbage collector. You decide when memory is allocated and freed, with helpers like defer, slices and checked nullable pointers to keep things safe.
  • Direct C interop. Eskiu speaks C's ABI, so it drops straight into an existing C and C++ engine like ViroCore without a heavy bridging layer. That's what let us migrate module by module rather than rewrite everything at once.
  • Modern language features. Generics with interface bounds, sum types with exhaustive pattern matching, operator overloading, and async/await with typed channels.
  • Self-hosting. The Eskiu compiler is written in Eskiu itself, and builds reproducibly through a three-stage bootstrap.

Here's a small taste of what it looks like:

extern int printf(string fmt, ...);

interface Drawable { void draw(); }

struct Circle {
    float radius;
    void draw() { printf("Circle(r=%f)\n", self.radius); }
}

void render(Drawable d) { d.draw(); }

int main() {
    let c: Circle = Circle { radius: 5.0 };
    render(&c);
    return 0;
}

If you've written C, Go or TypeScript, it should feel familiar pretty quickly.

Why we made it

We could have kept squeezing more out of C++, and for a lot of ViroCore we still do. But we wanted two things that were hard to get at the same time: tight, predictable control over memory, and code that could be taken to a brand new platform without dragging a huge toolchain and runtime along with it.

Eskiu gives us both. Because it's ours, we can shape it around exactly the problems a cross-platform XR engine has, rather than working around someone else's priorities. It's the same philosophy that led us to build our own VPS and our own tracking engine for 3.0. Owning the foundations means we control how they evolve.

The impact so far

The results have been better than we hoped.

  • Up to 85% less memory in ViroCore. The memory-sensitive rendering modules we've migrated from C++ to Eskiu use around 85% less memory, across iOS, Android, Meta Quest and visionOS.
  • AR in the browser. Our visual-inertial tracking engine, the one behind ViroReact's Web AR, is built in C++ and Eskiu and compiled to WebAssembly. Feature detection, optical flow, bundle adjustment, relocalisation and plane detection, all running in a browser with no native AR framework.
  • AR on a Nintendo 3DS. As a fun stress test, Eduardo got that same core running an on-device AR demo on a Nintendo 3DS, a 32-bit ARM11 handheld from 2011. Nobody is asking for AR on a 3DS, but if the core runs there, we're confident it can run on the custom hardware we're heading towards.

For ViroReact developers, the best part is that you don't need to change a thing. Your apps simply get a lighter engine underneath them.

See it for yourself

We've put together a page in the new Labs section of our website that shows where Eskiu runs inside ViroCore, along with code samples and case studies:

It's open source

Just like ViroReact, Eskiu is open source under the MIT licence. You can find it on GitHub, and installing it on macOS or Linux takes one command:

curl -fsSL https://eskiu-lang.org/install.sh | sh

Have a play, break things, open issues. We'd love to know what you build with it.

What's next

Eskiu is still young, and we're going to keep moving more of ViroCore over to it as we take ReactVision onto more devices. I'm really excited about where this goes, and we'll be sharing plenty more as we continue to build it.

A huge thank you to Eduardo for building something this ambitious. Watch this space.

Oli