Richard Feldman:
However, we have decided to do a scratch-rewrite in a different language—namely, Zig. We’re very excited about it!
Here are some relevant comparison points between the two languages in the specific context of Roc’s compiler in 2025:
- For many projects, Rust’s memory safety is a big benefit. As we’ve learned, Roc’s compiler is not one of those projects. We tend to pass around allocators for memory management (like Zig does, and Rust does not) and their lifetimes are not complicated. We intern all of our strings early in the process, and all the other data structures are isolated to a particular stage of compilation.
- Besides the fact that Zig is built around passing around allocators for memory management (which we want to do anyway), it also has built-in ways to make struct-of-arrays programming nicer - such as MultiArrayList. We have abstractions to do this in Rust, but they have been painful to use. We don’t have experience with Zig’s yet, but looking through them, they definitely seem more appealing than what we’ve been using in Rust.
- Rust’s large ecosystem is also a big benefit to a lot of projects. Again, Roc’s compiler is not one of them. We use Inkwell, a wrapper around LLVM’s APIs, but we actively would prefer to switch to Zig’s direct generation of LLVM bitcode, and Zig has the only known implementation of that approach. Other than that, the few third-party Rust dependencies we use have equivalents in the Zig ecosystem. So overall, Zig’s ecosystem is a selling point for us because once you filter out all the packages we have no interest in using, Zig’s ecosystem has a larger absolute number of depedencies we actually want to use.
- Zig’s toolchain makes it much eaiser for us to compile statically-linked Linux binaries using musl libc, which is something we’ve wanted to do for a long time so that Roc can run on any distro (including Alpine in containers, which it currently can’t in our Rust compiler). We know this can be done in Rust, but we also know it’s easier to do in Zig. Zig’s compiler itself does this, and it does so while bundling LLVM (by building it from source with musl libc), which is exactly what we need to do. Once again, we can reuse Zig code that has done exactly what we want, and there is no equivalent in the Rust ecosystem.
- There are various miscellaneous performance optimization techniques that we’ve wanted to use in Rust, but haven’t as much as we’d like to because they have been too painful. For example, we often want to pack some metadata into some of the bits of an index into an array. Zig lets us describe this index as a struct, where we specify what each of the bit ranges mean, and that includes arbitrary integer sizes. For example, in Rust we might store an index as a u32, but in Zig we could break that into a u27 for the actual index data (when we know the index will never need to exceed 2^27 anyway), and then we can specify that we want to use another 3 bits to store a small enumeration, and the remaining 2 bits for a pair of boolean flags. Again, these are all things we could do using Rust and bit shifts, but it’s much nicer to do in Zig. Tagless unions are another Zig feature we expect to be valuable.
Did I mention compile times? I’ll reiterate: compile times are a huge deal. Not only have they been painful in Rust, we also know that the fundamental unit of compilation is a crate, so we’re incentivized to organize our code around what will make for faster compile times rather than what makes the most sense to us as authors. Often the boundaries end up being drawn in the same place regardless, but when those two are in tension, it’s frustrating to have to sacrifice either feedback loop speed or code organization. In Zig we expect we can just have both.
This is a large amount of effort to invest knowing you’ll need to do it again to make the complier self-hosting, so they must be pretty unhappy with the current implementation. The project was already using Zig for the Roc standard library having replaced the Rust version some time ago, so it seems like they’re going in fairly well informed.
Consider me dubious of that memory safety claim. It’ll be interesting to see if memory related bugs that would be prevented by Rust show up in the new implementation.
Roc contributor Brendan Hansknecht on Lobsters:
Our rust compiler implementation definitely could compile a lot faster. A huge pain to the compile times is the fact that it grew organically. If we were to rewrite it again in rust, I’m sure it would compile a lot faster.
These times are from an M1 mac. They are approximately the same as an intel i7 linux gaming laptop (used to be the m1 was way faster, not sure when they became even). All of the below is just building the roc binary. Building test and other facilities is much much worse (and we already combine many tests binaries to reducing linking time, though we could do it more).
After change something in the cli (literally zero dependency and best case possible):
Finished dev [unoptimized + debuginfo] target(s) in 4.15sAfter changing something insignificant in the belly of the compiler:
Finished dev [unoptimized + debuginfo] target(s) in 16.95sAnd for reference, clean build:
Finished dev [unoptimized + debuginfo] target(s) in 1m 58s
It’s not uncommon for a rewrite to yield benefits just from being a second implementation. It sounds like this would partly be the case here too: a second Rust implementation might be able to be constructed in a way that makes it faster to compile. However, the same way you can make JavaScript fast using specific patterns that play to the JIT compiler, it’s nicer when it’s just fast by default.
Personally the heavy focus on compile times doesn’t really resonate with me—and that’s ok—they’re clearly a huge deal to Richard. The features each person values in a language vary by person. Having come from the dynamic language world with constant runtime errors I was drawn to Rust because it was able to eliminate whole classes of errors without compromising on runtime performance. I’m happy to trade a few seconds of compile time to know that it’s quite unlikely I’ll ever have to be debugging NULL pointers, segmentation faults, or data races in production software.
Via Lobsters