How Our Rust-to-Zig Rewrite Is Going

by jorangreef • 6 days ago

530 305 6 days ago

Didn’t know Roc was still being worked on. I think it’s an interesting concept for a language that I personally haven’t seen elsewhere

sarchertech• 6 days ago

What made you think it was no longer being worked on?

denismenace• 6 days ago

What concepts do you find interesting, compared to other FP languages?

onlyrealcuzzo8• 6 days ago

Zig's incremental builds are DEFINITELY a killer feature. In the short term, I could see why you'd make a switch to get it. But, in the medium term, can we really not expect to see this in Rust in the somewhat near future?

I want to go fast, but I don't want to go fast just to shoot my foot off.

If only somehow we could get Rust's safety with all of Zig's features and Go's runtime without GC...

That's what I'm working on building [=

Hinrik• 6 days ago

Layperson here: what is special about Go's runtime, aside from the GC?

onlyrealcuzzo8• 6 days ago

It's literally the most sophisticated scheduling engine in the world.

In practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory.

That's how good the Go scheduler/runtime is.

fnord77• 6 days ago

Goroutines?

djha-skin2• 6 days ago

Chief design goals were radically easy concurrency and speed of compilation.

vips7L2• 6 days ago

Is the Go GC that special? Is it even generational yet?

lioeters3• 6 days ago

Instead of waiting for faster compiler in Rust, how about from the other direction, adding some kind of borrow checker to Zig? That sounds more within reach and practically achievable, possibly even in userland.

onlyrealcuzzo8• 6 days ago

That's sort of what I'm doing...

I'm writing a language with Affine Ownership that transpiles to Zig and has a built-in FSM-based Green Fiber runtime.

Affine Ownership gives you memory safety + fearless concurrency + eliminates the need for Go's GC.

It's obviously going to slow down compilation - since you need to do Rust's borrow checking, etc. But I can do this incrementally as well...

dnautics23• 6 days ago

how about from the other direction, adding some kind of borrow checker to Zig? That sounds more within reach and practically achievable, possibly even in userland.

It's doable, and as static analysis. see sibling comment.

veber-alex3• 6 days ago

It's impossible to add a borrow checker to any existing language.

The reason Rust has a working borrow checker is because every part of the language from structs, enum, traits, generics and all the way to the syntax itself has been designed to support lifetimes and borrow checking.

It's is not something you can just tack on to an existing language without fundamentally changing it.

dnautics23• 6 days ago

if only somehow we could get Rust's safety with all of Zig's features

i periodically throw my unused codex tokens at this:

https://github.com/ityonemo/clr

dabinat• 6 days ago

This is being worked on: https://rust-lang.github.io/rust-project-goals/2026/roadmap-...

Most of the goals on this page are targeted for this year.

insanitybit3• 6 days ago

Rust's compile times will get faster long before Zig gets safer.

onlyrealcuzzo8• 6 days ago

I'm pretty sure Zig has no plans to ever become safe - by any sane sense of the word - so, yes, I would expect...

Gigachad2• 6 days ago

Are compile times that big of a deal? I haven't used Rust a ton, but the few times I have it seemed like the bulk of the compile time was a one off compiling the crates, and then compiling your own code was super fast.

I feel like I'd massively prefer to end up with a binary free of memory exploits than shaving some time off compile.

KoleSeise1277• 6 days ago

The 35ms incremental rebuild is the part that sold me. I'd be curious to see the same benchmark on ARM once -fincremental gets there.

mlugg• 6 days ago

Zig team member here---obviously I can't say for sure yet, but I'm pretty confident the number will be basically identical. In the Zig compiler, incremental updates (rebuilds) have a small amount of overhead which is roughly proportional to the total size of the codebase (rather than just the amount of code which was changed). This comes from a) detecting which source files changed, and b) traversing a graph to figure out which declarations are referenced (necessary due to Zig's "lazy analysis" feature). But performance analysis reveals that for small updates, this overhead actually dominates the update time, by a lot. Of the 35ms, I would guess that under 5ms are actually spent rebuilding the function(s) that changed. Of that 5ms, code generation---the only thing which would really be different on AArch64---is an even smaller slice of the pie (it often doesn't even impact the overall time, since it runs in parallel with other parts of the pipeline, and those other parts are usually the bottleneck there). So even if the AArch64 backend was significantly slower (which, right now, is the opposite of what we expect---instruction selection and encoding for x86_64 is unusually complicated!), I wouldn't expect the number to change from 35ms.

steveklabnik24• 6 days ago

I think this is a fine post. But one comment:

remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job

I don't really think that this is true, in the way that it's written.

I think that for the hot binary patching / code reloading features, yes, that is going to need unsafe. But for regular old "producing an executable" compilation? Emitting machine code isn't the part that requires unsafe. The language's runtime is a more likely site to find unsafe.

paulddraper• 6 days ago

Agreed, that’s disturbingly incorrect.

If anything, compilers are perfect models of trees and well formed programs.

benj111• 6 days ago

Maybe in theory. In practise you have thing like super optimisers. You have side effects that the compiler needs to understand etc.

That said I'm struggling to think of something that would need to be unsafe.

Aurornis5• 6 days ago

That line confused me, too. What parts of their compiler require memory-unsafe operations to produce machine code?

skybrian2• 6 days ago

They are saying that running the compiled code is memory-unsafe when there is a compiler bug, and that’s what developers do next. The memory corruption happens in a different process.

In this respect, effectively all the compiler should be treated sort of like an unsafe region because it requires extra care to avoid memory corruption bugs.

EPWN3D2• 6 days ago

Yeah that is definitely 1000% wrong. A compiler can do its job with totally abstract data structures. If anything would need to do unsafe stuff in memory, it would probably be a linker.

steveklabnik24• 6 days ago

probably be a linker

I don't think that's any different either. The core job of linking isn't particularly unsafe.

(Unless, similarly, you're doing the hot reloading stuff)

orlp• 6 days ago

I think if you interpret it charitably it means that any bug in the emitted machine code is already a likely memory-unsafe miscompilation if it is ran.

The compiler itself might be perfectly "memory safe" but the generated binary fundamentally is always at risk (besides WebAssembly I suppose).

I'm fully aware of the separation of compiler and binary, and being able to compile untrusted code safely is nice, but a perfectly safe compiler that generates vulnerable binaries isn't that much better.

steveklabnik24• 6 days ago

I do think that is a good point, it's just not what the line actually says. But that's why I wasn't saying "zomg this is WRONG!!!!" but instead, trying to point out that there are subtleties here. For people who aren't as deep in the weeds in this subject, I think the details matter. But again, as I said, I like the post, this is just one thing.

I am also probably in a more pedantic mindset because, well, I'm writing a compiler in Rust, and the words as written do not resonate with me at all.

a perfectly safe compiler that generates vulnerable binaries isn't that much better.

I do think it's much better. Eliminating classes of bugs in one component is a good thing, even if it's not every component. This is a core lesson of Rust! unsafe still exists, but going from "I don't know what is unsafe" to "only this part is unsafe" is a major improvement.

demosthanos3• 6 days ago

In context that's clearly not what he's saying, the next sentence is this:

Zig has more features than Rust for making memory-unsafe code work correctly, and that was the area where we wanted the most help.

Zig definitely does not have more features for successfully emitting memory-unsafe machine code than Rust does. I can emit memory-unsafe machine code from typescript if I really want to and nothing at all in the language will get in my way. So the sentence quoted above must refer to the idea that the compiler itself needs to be unsafe, which Steve is right is simply untrue.

Aurornis5• 6 days ago

The section this came from was talking specifically about usages of `unsafe` in the compiler code.

It's not about the memory safety of the resulting binary.

rtfeldman3• 6 days ago

I think that for the hot binary patching / code reloading features, yes, that is going to need unsafe. But for regular old "producing an executable" compilation? Emitting machine code isn't the part that requires unsafe. The language's runtime is a more likely site to find unsafe.

Agreed! Emitting machine code is not unsafe, since it's just writing bytes down - it's only once you execute that machine code that there's potentially unsafety. The reason I said "a big part of the job" is that in practice a lot of compilers both emit machine code and execute it - but you're totally right that it's not a requirement that a compiler do both.

In addition to the examples you gave (hot binary patching/code reloading, language runtime, etc.), others would be things like evaluating userspace code at compile time (e.g. const fn in Rust, or in Roc any expression that could be hoisted to the top level), running tests and inspecting their output to decide what to display to the user, etc.

Those are the types of things I had in mind when I wrote that.

steveklabnik24• 6 days ago

I am disappointed you're downvoted, Richard. This is a fine reply, and I hope you know that a minor quibble with a single line in the post doesn't mean that I think it's a bad one overall. (EDIT: a few minutes later, the parent comment is no longer grey.)

I also think it's a good thing that you wrote the post in general, when I saw it pop up I was like "oh, of course, this post should exist!" I'm surprised I didn't think about it earlier.

evaluating userspace code at compile time

Usually this would be done via an interpreter, so I'm not sure that it really requires unsafe either. If you are literally executing machine code, sure, but const fn in Rust and constexpr in C++ and many other languages do not do that, as it causes a number of problems (for example, cross-compilation).

psychoslave• 6 days ago

Side concerne, but reading the post initially I thought it was about Rocq (formerly Coq). Maybe both team could coordinate and find a way that everybody agree on to avoid any confusion?

https://en.wikipedia.org/wiki/Rocq

narnarpapadaddy2• 6 days ago

I agree that it’s not inherent to emitting machine code but I do think it reflects a different set of priorities.

In extremely high performance code you use different data structures and algorithms and change your approach to memory allocation. TigerBeetle famously does all memory allocation once on startup.

Roc is attempting to make a similar set of trade-offs in their compiler as Zig, so it makes sense that the author finds many shared patterns.

steveklabnik24• 6 days ago

I do think it reflects different priorities, but one of those differences is that from my perspective, safety and performance are not inherently at odds. Yes, sometimes it is needed, but not as much as some people seem to think. Sometimes, it also means writing code in ways that communicate things to the compiler that you may not think of if you're not used to thinking in this manner.

A lot of the ways in which the zig compiler works doesn't use pointers, it uses indices. This stuff is easier to write as safe code, not less easy.

Roc is attempting to make a similar set of trade-offs in their compiler as Zig, so it makes sense that the author finds many shared patterns.

I do think that that makes sense, but it also doesn't mean that they have to. I am doing a compiler project that takes a lot of inspiration from Zig (as my language currently inherits some major things from Zig, and I also care a lot about compiler performance) and it's written in Rust, and does not use much unsafe code (outside of the usual suspects of FFI in the runtime, etc).

nicoburns• 6 days ago

In extremely high performance code you use different data structures and algorithms and change your approach to memory allocation.

It's worth noting that the reason Rust doesn't include support for custom memory allocation patterns like Zig does has nothing to do with memory safety. It's more of a historical accident that it just wasn't something that was prioritised early in the projects history and is now hard to change.

pjmlp19• 6 days ago

Many people try to twist the fact memory safe languages have unsafe code blocks to make the pivot that why bother.

It is like someone arguing that since they always bump the head somehow while wearing seatbelts, then they are only a nuisance and should not be used.

tadfisher• 6 days ago

Because they view "unsafe" as an escape hatch instead of a feature. It's a way to encapsulate dangerous behavior, tightly, with clear postcondiitions. Sometimes it's the only way to do things like interact with inherently unsafe FFI code, or hardware.

maybebug2• 6 days ago

Memory safe languages, where usage of Miri and Valgrind (tools to for instance debug memory unsafety) are common and integrated into CI for some of the projects in the language. Even some Rust guides encourages running Miri in CI https://microsoft.github.io/RustTraining/engineering-book/ch... . Searching on GitHub yields a lot of projects that run Miri in CI. And there have been a lot of CVEs for Rust projects caused by memory unsafety.

Interesting perspective that you have.

ploxiln• 6 days ago

I think it's a reaction to many simpler advocates of Rust saying "it's unsafe and irresponsible of you to not use Rust, you can't write software in C or C++ or Zig (or Go?) and have memory unsafety and put your users at risk, it's not safe, you have to use Rust to be safe".

Freakin' safety. I like doing lots of unsafe things in life: rock climbing without gear (short bouldering sections on hiking trails), bicycling and skateboarding without a helmet, etc. I developed pretty good skills in all these things, and programming C too. What kind of life would be worth living with enforced perfect safety? Without developing skill in life's many un-safe activities?

So people want to emphasize that, if they shouldn't use non-Rust languages because their safety can't be guaranteed, well your safety using Rust isn't absolute, either. So you can't tell me I must use Rust, or the Rust rewrite of my favorite tools, to "be safe".

Do you recall the early rust web framework, that used a lot of "unsafe" "inappropriately" and had some vulnerabilities ... actix web? ... reminds me of the bun-in-zig situation, kinda makes the language's PR situation more complicated and tricky.

gabriela_c• 6 days ago

I don't really think that this is true, in the way that it's written.

Well, it's true when it's written badly (eg. the same way as when somebody writes in-line "shellcode" by doing `*(T*)ptr = (T)val;` or similar.

I think there's some history of some compilers that were basically non-trivial to port to other architectures/bit-sizes b.c. of this piggybacking.

landr0id3• 6 days ago

ReleaseSafe catches use-after-free errors through runtime checks which panic if the program tries to use freed memory.

I don't know Zig so maybe they know something I don't, but I have seen no evidence that it catches any type of use-after-free including double-free?

While writing a blog post (below) I went through the documentation to figure out the possible runtime memory safety checks Zig can insert. The term "use-after-free" or "UaF" never occurs on that documentation page. Searching for "safety-checked" doesn't yield any related hits either.

Unless maybe they're using the DebugAllocator in release builds? Even that does not reliably surface UaF.

https://landaire.net/memory-safety-by-default-is-non-negotia...

veber-alex3• 6 days ago

I believe you are correct.

I think ReleaseSafe just adds bound checking and panics on unreachable code.

I don't think Zig offers any temporal memory safety.

flohofwoe• 6 days ago

The DebugAllocator catches use-after-free (at least on page-level), but at the cost of never recycling memory addresses (e.g. it eats through the virtual address space).

https://ziglang.org/documentation/master/std/#src/std/heap/d...

For higher level code, "generation-counted index handles" might be the better solution to provide temporal runtime memory safety, not part of Zig the stdlib though.

Or even better: never use dynamic memory allocation and make all lifetimes 'static' :)

Quot• 6 days ago

I don't know enough about Zig to explain it, but there is more to ReleaseSafe than checks and panics. ReleaseSafe also clears memory that no longer has an owner (I might be describing that wrong, that is just how I understand it). I found this out with a rendering issue recently.

The bug was around passing a slice to OpenGL which referenced memory outside of its lifetime. Since the memory location had no owner, vertices would still exist in Dev builds and everything would work fine, but in ReleaseSafe the application would run and just have nothing to render.

Since OpenGL was trying to read the memory, there was no panic from Zig, but it was a cool look into how the different build modes handle memory.

This is the commit where I fixed the issue: https://github.com/quot/donut/commit/8fff107e76278c4bf55007c...

azakai2• 6 days ago

Zig does offer some amount of temporal memory safety.

Link: https://zig.guide/standard-library/allocators/

Text:

The Zig standard library also has a general-purpose debug allocator. This is a safe allocator that can prevent double-free, use-after-free and can detect leaks.

For more detail, see:

https://github.com/ziglang/zig/issues/3180#issuecomment-5284...

minraws4• 6 days ago

I as someone with writing Zig a bunch, can safely say if it does it hasn't even worked for me.

I am talking from experience from a pre-ai human mitts writing code perspective maybe Zig + LLMs do some magic.

The more I read the article the more I feel like this is just bad not sure if I should be giving it as much latitude as I have been in my prior comments.

There are other claims as well that are weirdly phrased at least.

Reads like an article written to justify some arguments they had rather than a genuine take at this point.

But I will give the benefit of doubt I enjoy weird articles, languages and share a dislike for aggressive AI-ness of all things.

arthurbrown2• 6 days ago

Interesting that OCaml was flexible and expressive enough to be used as a prototype testbed but not chosen as the implementation language, especially given the maturity of both. I would be surprised if Zigs incremental builds could be meaningfully faster than dune's.

Cross compilation is great, but not mentioned in the "why Zig" section. Is memory control that crucial for a compiler?

Rust itself was originally written in OCaml, same with WASM. I'm curious about what milestone gets reached where the maintainers collectively decide to transition away.

steveklabnik24• 6 days ago

Rust moved away from OCaml when it decided to be re-written in Rust. The post alludes to this as being a usual time for a wholesale re-write, and I'd agree.

arthurbrown2• 6 days ago

I appreciate the insight, and on closer reading the post clearly states that realistically only Zig and Rust were ever considered anyway.

Since you're here, could you comment on the approach Rust took in their rewrite? Was it more of a straight translation like Go did when they self hosted -- similar to the recent Bun transliteration? Or were there architectural changes made along the way like this article describes with Roc?

grayrest3• 6 days ago

One of the primary goals for the Roc project is compiler speed. I presume OCaml is out of the running because it's not a systems language.

satvikpendem• 6 days ago

OCaml compiler is incredibly fast. I wonder how it'd fare with Jane Street's extensions for the borrow checker etc in OxCaml, if it's good enough for their HFT I'm sure it's good enough for a new language.

steveklabnik24• 6 days ago

OCaml has often historically been considered a language that's been appropriate to write systems tooling like compilers, runtimes, and unikernels in, even though GC'd languages were/are not often considered for such projects.

pjmlp19• 6 days ago

Depends on the beholder.

Unix system programming in OCaml

https://ocaml.github.io/ocamlunix/

https://mirage.io/

up2isomorphism• 6 days ago

I think there will be soon a wave of rewriting rust to language X coming up.

echelon• 6 days ago

The other way around.

Rust is also one of the best languages to use with AI.

skhameneh• 6 days ago

I like Rust and I'm an advocate of Rust, but this really isn't true (at least it hasn't been and I doubt much has significantly changed).

The syntax complexity and the ecosystem haven't been ideal for LLM development. And there have been publications on findings of LLM efficacy with different languages. Rust is most often towards the lower end of efficiency/correctness when benchmarked.

https://arxiv.org/html/2508.09101v1

guywithahat• 5 days ago

I've sort of thought this too. Rust adoption feels a lot like Haskell to me in that it's centered around ideological things that don't really improve the final product and arguably slow development. If your goal is to write a bunch of LLM code there are better languages than rust, and rust development is often regarded as too annoy for anyone not enthusiastic about the ideological improvements.

There are cool ideas in the language but I don't see it enduring over time.

dev_l1x_be• 6 days ago

Zig is a pre-1.0 language while Rust is post-1.0. This alone is settles which one to pick for may developers. The library support is probably favours Rust too. Rust build times are much slower than Zig, I get that, but I rarely optimize software for build times.

drdexebtjl4• 6 days ago

Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes.

Nowadays when you can just point an agent at release notes and have it update everything, I actually prefer not having to wait through rare major releases to get new language features.

afdbcreid9• 6 days ago

Nowadays when you can just point an agent at release notes and have it update everything

Except that means that not only you lose compiler bugfixes, you also pretty much has no access to the ecosystem. For most production codebases, this is a deal breaker.

rwz• 6 days ago

they want to be able to make breaking language changes

That sounds like it's not ready for production to me.

Aurornis5• 6 days ago

Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes.

This is a solved problem in other projects. Either use the version numbers as intended and bump the major version number on breaking changes, or use Rust-style editions to opt in to the newer versions of the changes.

Calling a project production-ready but keeping the version number below 1.0 and saying breaking changes are expected is a tired game. We've seen it backfire across a number of language projects like Elm, where the exact same claim was used to both encourage people to use it and then blame them when it backfired.

If it's production ready, go to 1.0 and then follow semver for breaking changes. I don't care if we get to Zig v73.2.0 as a result. At least we can see from a glance which versions need to be checked for breaking changes.

audunw2• 6 days ago

That’s totally reasonable. But while each minor version has breaking change, a minor version release itself is generally fairly stable and useable. There are solid production software which is already using Zig, like TigerBeetle and Ghostty/libghostty.

I am waiting for (near) 1.0 myself before doing anything major with it. But that’s mainly because I want at least the async IO stuff to be settled for my use cases.

LAC-Tech2• 6 days ago

Counter Argument - with Zig it's perfectly viable to make programs using just the standard library. You have json serde, zon (zig object notation) serde, system functions (ie libc/rustix equivalent), random number generators... all without a single dependency.

satyambnsal• 6 days ago

is this uno reverse for bun post of zig to rust port ?

giancarlostoro3• 6 days ago

One thing I wish Rust would improve over time is the builds. Its one of the biggest sources of wasted storage space on all my computers, builds a ton of libraries can take tens of gigs, it adds up very quickly. Not sure what the best solution is, one I found is to set the global build folder so dependencies get reused across projects, but imho it should be an OOTB default behavior whatever the real solution should be.

c-hendricks• 6 days ago

I always got a kick out of that, coming from a JavaScript background where people constantly harp on the size of node modules.

My Tauri project, where the backend is much smaller code-wise than the frontend, has 9gb of rust artifacts (node_modules is 550mb for comparison)

tredre3• 6 days ago

Rust isn't great, and it shouldn't be a surprised since it's designed after npm. However one metric where nodes_modules is still worse for me is the sheer number of small files in it.

Having nearly one million files in nodes_modules isn't that unusual. The problem is that on most common file systems the minimum allocation is usually at least 4KB. So even if the actual data is less than 500MB, you end up with 4GB disk space used/wasted.

epage• 6 days ago

We are trading away disk space for faster builds. We could make them faster in some cases by using even more...

On the other hand, it would be good to garbage collect those caches. We are wrapping up work on a new layout for intermediate build artifacts that will make it easier to GC them.

kstrauser• 6 days ago

Can you talk a little more about that? How would that work, and what would the developer experience be like when using it?

giancarlostoro3• 6 days ago

Sounds like what I was thinking, that or for third party deps to go into the same temp folder, and anything not accessed in over a week, or so just gets auto wiped by rustc / cargo build process?

burnt-resistor• 6 days ago

Use sccache.

pjmlp19• 6 days ago

Quite interesting the hand waving of security issues with Zig, oh well.

If I want to use allocator debuggers I already have the production ready tools that exist for C and C++ for at least 30 years.

afdbcreid9• 6 days ago

Compilers are not security sensitive, usually. And while UB could theoretically poison the generated code, this isn't a bigger risk than logic bugs.

pjmlp19• 6 days ago

Of course they are, anything can be a gateway to inject backdoors, if security is not taken into account.

And as mentioned, if what Zig offers is already in Purify, there is hardly any added value over C and C++, without the headaches of a niche language.

demosthanos3• 6 days ago

Compilers are not security sensitive, usually.

The compiler is one of the most significant trust boundaries we have. Its decisions can intentionally or unintentionally create vulnerabilities in programs compiled by the compiler, which means that if you can compromise a compiler you can compromise everything downstream.

Unsafe memory access in a compiler can be exploited in order to hijack the compiler itself (this is reported regularly in production compilers), allowing the attacker to then insert arbitrary code into compiled binaries. Not everything that a compiler absorbs from its environment is meant to be treated as source to be compiled, and in a memory unsafe compiler any of that input can silently turn into machine code in the compiled binary if an attacker is able to exploit the memory safety bug and hijack the compiler.

royal__• 6 days ago

I don't even know what Zig is but I've seen this topic come up so many times on this site that I'm starting to think the people who are actually doing this are unsure themselves whether it's a good idea or not.

pjmlp19• 6 days ago

Basically the security model of Modula-2 or Object Pascal, with a curly brackets syntax, and compile time execution.

Some folks embrace it as some kind of novelty.

uaksom3• 6 days ago

It does seem like they're trying to convince themselves. If you like Zig, that's a good enough reason to use it. Why waste time on language tribalism?

I have the same issue with "use the right tool" rhetoric. The right tool is the one that does the job and that you know best.

dminik2• 6 days ago

While I'm a rust enthusiast, I do agree that certain languages lend themselves well to particular domains. So a rewrite from Rust to something better suited is fine by me. In fact, while I do work on a rust project, I would not have and still would not recommend it as the choice for that particular project.

That being said, I had to do some double takes while reading this.

https://rtfeldman.com/rust-to-zig#memory-safety-post-rewrite

I feel that it's a bit weird to compare a rather well tested 7 (?) year old rust implementation with a brand new not yet released less than a year old Zig implementation. Without that context, this looks like a bad comparison for rust, when it is in fact the complete opposite.

https://rtfeldman.com/rust-to-zig#build-times

The swiftness of the Zig compilere here is insane, and would would very much shift my recommendation of Rust if it got to similar speeds.

That being said, I do find it funny that currently, the compilation speed is actually worse on Zig than Rust, despite Zig (anonymous commenters at least tbf) claiming the opposite for years.

How did you eventually discover the 35 ms figure for Roc? Did you have to temporarily update the codebase to 0.17?

https://rtfeldman.com/rust-to-zig#memory-control-zero-parse-...

Nothing negative here. I did play around with implementing a scripting language in this DOD-ish, index-based paradigm and yeah, it is neat.

I was thinking that it might be possible to do resumable computation across the network like this (in the context of frontend frameworks "resuming" UIs), but ultimately I have no use for this so just the experience itself was enough.

One note here is that it does tend to break completely if non-pointer-free data is introduced. It seems like it's either all or nothing.

https://rtfeldman.com/rust-to-zig#ecosystem-relevance

This is more of an LLVM thing, which is fair, but I find it funny that "LLVM unstable bad" while "Zig unstable whatever".

Overall though, this was an interesting read. And if the folks contributing to roc like zig then more power to them.

Last thing, the link here is broken (points to a TODO):

Zig's compiler itself is another

andriy_koval• 6 days ago

In fact, while I do work on a rust project, I would not have and still would not recommend it as the choice for that particular project.

wondering what type of project is that? I think besides some very embedded projects with very little memory where you need C/assembly, rust is good enough for all kind of projects..

dminik2• 6 days ago

I work both on a pretty much bog-standard web (GraphQL) backend and the frontend that uses it. We switched over from Apollo on node to async-graphql on Rust.

The runtime performance is much better, but the compiler time performance is terrible. To be fair, this is mostly the fault of async-graphql, but that doesn't really matter all that much. For example, it's not uncommon for a single character SQL query change to trigger over a minute long incremental rebuild.

The rust compiler is just choking on the number of generics and codegenned functions.

I've personally looked at how to improve this, but short of breaking up the type graph using federation, nothing can help. Not even cranelift makes a noticeable dent.

Additionally, the team started off composed by a bunch of TypeScript/React/Node developers, so mistakes were made along the way.

Honestly, I would have recommended to just use C#.

That's not to say that I don't think Rust can work for web development. We have some (GraphQL-less) services where Rust is a great fit. Just maybe shouldn't have been the default. That or give up graphql ...

maybebug2• 6 days ago

Nitpicking ahead:

I am not sure, but there might be a bug in their pattern matching example.

What happens if 'verb' is "GET" and 'path' is "/users/1234/posts/1234/extra_path/and/more/"? Will 'post_id' become "extra_path/and/more/"?

I tried running it in the sandbox, and it does indeed seem to buggily result in:

"Post ID: 1234/extra_path/and/more"

I suspect that the reason it is behaving like it is, is due to how it handles characters in the string literal. The example program exploits that only the slashes present in the string literal pattern are matched, to enable matching on 'page' having slashes. But then in the nested 'match', it forgot to account for any possible extra slashes.

Nitpicking end.

I have not read the whole post yet, but the pattern matching not requiring any allocations, seems very nice. The string literal patterns also seem interesting, though I am not completely sold on them, also as per the above possible bug. It seems really clean in some ways, but the specific semantics, I am not fully sure about. Maybe it is excellent, and is so clean and concise that it is overall less bug-prone than alternatives in other programming languages. I do not know.

stymaar• 6 days ago

Irrespective to the technical merits of both language, moving from a stable language to a pre-1.0 one that just lost his most popular open source project is a wild move.

estebank3• 6 days ago

that just lost his most popular open source project

As they state in the article, they started the migration a year and a half ago, something that happened a few weeks back would never come into the decision making process.

norir• 6 days ago

This piece would have been a lot more compelling if they had actually done science on selecting a language for compiler development. From what I can tell, they had an untested hypothesis that a low level systems language is necessary for a high performance compiler https://www.roc-lang.org/faq#self-hosted-compiler and from that concluded that their only choice besides rust was zig.

I know from experience that this initial assumption is wrong. Compiler performance is dominated by algorithms. The fastes managed languages tend to be at worst within a factor of two for wall time on any given algorithm. Algorithmic differences can be unbounded in their performance gaps. Zig itself is a perfect counterexample to the theory that writing a compiler in a low level systems language will lead to a fast compiler. Roc seems to compile at around 15k lines per second. That is not fast. There were evidently compilers written in ml that did 3k likes per second in 1998 https://flint.cs.yale.edu/cs421/case-for-ml.html

The zig rewrite of roc looks like the author's second compiler. Compiler and language design is a skill like any other and from my vantage point, they appear to have overcommitted to an initial design at the expense of developing their higher level design skills. In my opinion, the best thing they could do for the future of roc is stop working on their current compiler and use it to write a self hosting compiler for a much smaller subset of roc. They should be able to do that in less than 10k lines of code. They might even find that their self hosting compiler is faster than their zig based bootstrap compiler for the self hosted subset of roc. If the self hosting compiler is inadequate. Now they at least have identified a smaller useful subset of roc and can experiment with different compiler implementations in 10k likes of code rather than 300k lines of code. Then they could actually test the theory of whether or not a low level language is necessary to meet whatever arbitrary compiler performance goals they have.

By self hosting, they would also discover what roc features actually matter and they would spend much more time actually writing roc code. The features that are needed to write a self hosted compiler are all features that are generally useful. By improving the self hosted compiler, they also improve downstream programs.

munificent• 6 days ago

Your comment is very assertive, but also doesn't offer much in the way of science.

Being able to compile ML quickly in the 90s tells you little about being able to compile Roc or some other language today because the language design enforces hard constraints on the algorithms necessary to compile it and the hardware today is much more complex. It's not hard to write a fast Pascal compiler that targets a 1980s chip with shallow pipelines. But that's not the problem being solved here.

I don't know much about Roc but it looks like it's got some amount of overloading and the linked article alludes to sophisticated algorithms to avoid heap allocating closures. Those can enforce algorithmic complexity in the compiler that is essential and can't be eliminated.

Once you're at the limits of algorithmic optimization, all that's left is reducing constant factors. I've written code in many languages in different performance regimes over the years and it's certainly the case that higher level languages, especially managed memory ones, put a hard floor in terms of how low you can go when optimizing to improve those constant factors.

I have seen in real-world code where explicit control over memory layout improved performance by more than an order of magnitude. I have friends in the game industry where much of their career is this kind of work. Those people would love to live in the luxurious world you describe where all they need to do is find a sufficiently clever algorithm and all of their performance problems will disappear.

emtel• 6 days ago

Compiler performance is dominated by algorithms

But you can always use the best algorithm no matter what your implementation language is, so it still makes sense to prefer a language that makes it easy to write fast code.

audunw2• 6 days ago

Did you read the article at all?

Zig itself is an incredibly fast compiler. And the language and standard library is designed to support writing that compilers. And yeah, that’s all about algorithm and data structures. A large part of why struct-of-arrays is easy to do in Zig is because Andrew wanted it for making the compiler fast. The article also points out that it’s reusing code from the Zig compiler source as well.

Roc may not be super fast now, but that doesn’t mean they haven’t seen ahead and set themselves up for success.

Yeah, I agree there is value in self-hosting as you say. Zig itself is an example of that. But zig is a systems language. If Roc isn’t aiming for that nice it might not be the best choice for writing a compiler in. As an example in the other extreme end of language flavours: Python is still mainly CPython and efforts to make a python interpreter in some variant of python hasn’t been particularly successful.

christkv4• 6 days ago

Can anybody explain to me why anthropic bought bun in the first place ?

steveklabnik24• 6 days ago

Claude Code uses bun.

christkv4• 6 days ago

Yeah I get they use it but I don't understand why you would buy it. it's just the runtime for code that makes up the agent.

3D39739091• 6 days ago

Nobody can.

"Claude Code uses Bun" is the reason that's given. But even though Anthropic tells us that "coding is solved", instead of rewriting Claude Code in something other than JS, they bought a company that made a JS runtime and then did a mass rewrite of that JS runtime.

Gigachad2• 6 days ago

Too much money, not enough ideas what to do with it.

dbacar• 6 days ago

why not rewrite in ROC?? Would be much more cooler.

I think precious cognitive time should be spent more on the language itself rather than wasting it on rewrites.

steveklabnik24• 6 days ago

The article links to https://www.roc-lang.org/faq#self-hosted-compiler to discuss this.

g42gregory2• 6 days ago

Does this mean every time you find yourself using lots of “unsafe” Rust blocks, it’s not the right tool for the job? I suspect it’s not that simple, but what are people’s experience?

steveklabnik24• 6 days ago

It really depends. For example, it might mean that you do not know the way to do the same thing, but in a safe manner. It might mean that you could refactor your code to do things more safely.

Of course, reasonable people may also believe that it is easier to use an unsafe language directly rather than change the ways that you code.

In my experience doing embedded, operating systems work, compiler work, and others, you never need a large amount of unsafe code. 1%/4% is really about it.

g42gregory2• 6 days ago

Makes sense. Thanks!

bbkane3• 6 days ago

Tangentially relates, but if any Roc devs are around I'm curious about the use cases for Roc.

It's supposed to be a scripting language right you embed into your C ABI right?

Do you see it competing with WASM for the plugin use case (i.e. a really large Roc platform)? Why would an app author prefer to expose a Roc layer to their app rather than a WASM layer? With a WASM layer, plugin devs can write in any language.

Another use case I've heard from it is as a more app-level language (i.e. a really small Roc platform). Do you see it competing with Gleam for server side http code? Do you see it competing with Elm for client side code?

SoftTalker• 6 days ago

Same question. I always like learning about languages I had not heard of, especially functional languages, so I was immediately curious what sorts of applications this might have. But after looking over the roc-lang.org website and the FAQ, I still don't know.

grayrest3• 5 days ago

If any Roc devs are around I'm curious about the use cases for Roc.

It's a general functional programming language that's interested in the constraints and state control properties but not really in the dogma/traditions. As a specific example, it has a for loop statement that doesn't return anything just because sometimes the algorithm is easier to express imperatively. That said, it really is functional, mutating functions/methods require a `!` suffix and `->` (pure) vs `=>` (not) is distinguished in the type system and enforced. The language is fully decidable so type annotations are optional with the arguable exception of the built-in Serde which needs a concrete type to encode/decode. It's also pretty fast, like in the Go range.

I think it has the best error handling of any language in the ~3 dozen I've tried. It's Rust style in general with `Result` renamed to `Try` but the error side of `Try` is an open tag set and can just aggregate so you get the nice parts of the Rust error experience without the downsides. As an example, a coeffect (effectful input) from an example on my server platform:

    book! = |req| {
        body : { id : I64 }
        body = Req.json_body!(req)?
        rows = Sql.query!(req.ctx, db_path, "SELECT id, title, author, year FROM books WHERE id = ?", [Integer(body.id)])?
        row = Sql.first(rows) ? |_| NotFound("book ${body.id.to_str()} not found")
        book = decode_book(row)?
        Ok(book)
    }

The full set of errors covers malformed utf8, missing/wrong type for id, db errors, the custom NotFound with message, and missing/changed db columns and these plus all the other errors across the app get rolled up and handled in one spot by the error mapping function which rolls the input errors to 400, a 404 for the NotFound, 500s in general in a big match. I have more compact ways to express this in the platform (sqlx) but those don't show off the error handling as nicely.

All in all, it's pretty much just a nice hosted language for doing things.

Do you see it competing with WASM for the plugin use case?

It's mostly competing with Lua and friends but the host is a platform and not an embedder so the Roc goes on the outside and produces the binary. Roc is particularly well suited for compiling to wasm because all the effects coming from the host is shared. This is actually one of my primary interests in Roc but I haven't really harassed the Roc team about it because they've been busy with the rewrite and wasm module specs have been WIP.

Why would an app author prefer to expose a Roc layer to their app rather than a WASM layer?

No need for the relatively large WASM runtime would be one of the first ones but Roc isn't really designed to be embedded. I expect to mainly use Roc for app level code on top of Rust for systems level code. I could write app-level Rust but I like functional programming, GC (refcount) is convenient, the error handling is nice, no annotations are nice, super fast compiles are nice, etc.

Do you see it competing with Gleam for server side http code? Do you see it competing with Elm for client side code?

Sure. As mentioned, I'm experimenting with a server platform that uses pure handlers plus an effect system. I have a RealWorld implementation and in casual benchmarking on my M1 laptop I get 69k req/s for the article endpoint (serialization bound) and 10k going through the article_list endpoint (sqlite bound, 4 table join). The framework also has full and automatic cache invalidation so if I turn on caching I hit 120-140k req/s on both endpoints with no other code changes.

As for GUI stuff, I'm working on a platform (Clay+Solid2) but I don't see any particular reason it wouldn't work.

bbkane3• 5 days ago

Thank you grayrest- I didn't realize Roc had to be the one that produced the binary.

Could you go into a little more detail about how you decide to split what's in your Rust platform vs your Roc application?

niclas-ahden2• 4 days ago

Another use case I've heard from it is as a more app-level language (i.e. a really small Roc platform). Do you see it competing with Gleam for server side http code? Do you see it competing with Elm for client side code?

For sure! I've been using Roc for work exclusively for the past year and a half, writing mostly full-stack web apps, and it's been great. I wrote a small framework/platform (https://github.com/niclas-ahden/joy) which is similar to Elm or Lustre from Gleam.

Previously I used mainly Rust/Haskell/Elm/Ruby/Python and each language has its pros/cons, but for web apps Roc really hits the sweet spot of: runtime performance, compilation speed, strong type system, error handling, and ergonomics. It's definitely worth a try!

bbkane3• 4 days ago

Thanks, I've starred your repo and I'll come back to it once Roc is more mature!

Fervicus• 6 days ago

Roc seems interesting. But for some reason I find it very grating to have the type definition on a separate line. Very much prefer F# syntax for that.

overgard• 6 days ago

Compile times are a really underrated thing. My #1 gripe with C++ is waiting 10 minutes on a build, it absolutely kills flow.

AlienRobot2• 6 days ago

I currently have a problem with Rust that I use Rust-Analyzer for syntax and autocomplete in VS Code and it has to run the compiler when you save a file to "refresh" things.

As you may imagine, this is insanely slow.

So slow that when I switch from a .rs file to a .ts file I feel like I switched computers.

jolt42• 6 days ago

My realization first time with Eclipse/Java.

dzonga• 6 days ago

even though I don't use Zig - a few things make me excited.

such as new games that are gonna come - written in Zig - since its more ergonomic than C.

the other side is on the distributed software side of things - we have already seen it with TigerBeetle.

on my own end - probably robotics side.

LAC-Tech2• 6 days ago

I enjoy Rust, I've taught a course on it, and I happily use it daily for my work at Zed. Despite what Internet comments might have us believe, it's extremely normal for one language to be the best fit for one project, while a different language turns out to be the best fit for a different project. One size does not actually fit all!

Amen. I like both Zig and Rust, and if I praise/criticise one of them, people act like I'm "switching", as if they were two exclusionary religions (though I think some people may indeed view them that way).

The stuff on memory safety written in the article is well worth reading, because in a lot of programmer discourse it's talked of as if it's some binary, that Rust Is Memory Safe, and Zig Is Not Memory safe. That's simply not the case.

feelamee• 6 days ago

As discussed earlier, having full control over allocations and deallocations is what I want in our compiler's implementation. And in tests, I also appreciate the testing allocators detecting leaks—it can even detect leaks in compiled Roc code! Unfortunately, to get that benefit requires a lot of "init this, defer deinit" code in tests that has to be correct or else the test fails on a memory leak. None of that is necessary in Rust. I care more about the compiler's implementation being the way I want it than the tests looking nicer, but in a perfect world I could somehow have both.

haha, just for fun... do you want a C++ in your perfect world :D?

arikrahman• 6 days ago

Saw Zig in the headline and worried they were going the way of Bun. Turned out it was the opposite and made for a good read.

lowbloodsugar• 6 days ago

though (more on this later) and we ended up with about 1,200 uses of unsafe (out of our 300K lines of Rust code

Rust code has a different source of memory-safety gaps: the unsafe sections that nearly every Rust program has somewhere in its dependencies. Unsafe Rust has all the memory unsafety risk of ReleaseFast Zig code, but none of the runtime checks to catch issues during development

Well if ReleaseFast would work for you then just write that in rust. The unsafe keyword can be used to write a shitshow, or it can be used to write small pieces of functionality, such as ArcUnion, that are safe to use. I don’t agree that every application has to have any unsafe code. If you find yourself needing it, then you go build the abstraction you need in another crate, miri the fuck out of that, and then just consume it in your application.

If you’re fine with the shitshow, then use zig, because that’ll improve rusts stats.

If you think you’re in the magical “I know what I’m doing and I need the extra performance” then you probably don’t know what you’re doing. You’re young. Knock yourself out. I’ve written assembly language hackery for video games you wouldn’t believe. Would I use any of that for a language others are going to use? You’re not that smart. And if you are, someone else on your project isn’t. Just a matter of time.

xiaodai• 6 days ago

Why? Zig is clearly not memory safe like Rust.

rienbdj3• 6 days ago

Seems like Rust unsafe could be improved without changing the language design.

Havoc• 6 days ago

Nice. I like this - adds a different perspective without adding drama

ksec• 5 days ago

Just reading the HN comments I found most interesting is that Rust and Zig have future improvement that related to each other's strong point.

Rust will be getting faster Build time in 2026 and 2027+. This post shows incremental build went from 10s to 3s in 18 months. And lots of improvement coming as well. While it may not be 35ms in Zig but it is not too far to imagine Rust could have 1s or even sub second incremental build in next 2-3 years.

On the other hand Zig is getting more tooling for memory safety. Opening Access to IR and even other ( although non official ) side project to have borrow checking implemented.

That is on top of the subject languages ROC, which for whatever reason really hit the "friendly" part for a functional language.

How Our Rust-to-Zig Rewrite Is Going

Related Stories