How Our Rust-to-Zig Rewrite Is Going • Hacker News Board

Re: How Our Rust-to-Zig Rewrite Is Going

#321

Post by grayrest » Sat, Jul 18, 2026, 2:12 AM UTC

bbkane wrote: post #318

grayrest wrote: post #316

Earlier quoted context omitted.

> 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…

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?

There isn't much in the way of libraries for Roc at the moment so the split is basically library vs application for my platform. I've been in the Zulip since well before the split but I've been waiting for the new version aside from playing around with the WIP when it first started working for Advent of Code. Reports from the past few weeks indicated it was close enough to ready for me so the web server is my first real effort. It's not generally ready (e.g. the compiler is crashing pretty regularly for me as I push into less common language features) but I'm enjoying myself and I do like the language design.

There is plenty of room for a more interesting nuance once the ecosystem grows:

I'm pretty pleased with my server platform so I'm making a stab at UI with a platform that's Clay and Solid2 ported to Rust. The Solid 2 model has pervasively asynchronous signals so components are written as if they're permanently live and simply don't get run until the constituent signals are ready. My thought process is that this is technically a pure model and only the input changes and effects are impure so there's a pretty clear Roc/Rust split. The platform is still in the assembly process so no actual experience to report. I'll be trying to avoid it but I expect to be doing code generation/compiler hacking in the effort.

On the other side is Luke's roc-signals [1] which explores how the signals model works if all the signal engine code is in Roc with only a minimal backing platform for holding the mutation: "We may not add dataflow analysis passes, dependency-graph extraction, or any new compiler behavior. Everything is ordinary Roc plus a Zig host."

[1] https://github.com/lukewilliamboswell/roc-signals/blob/main/...

Re: How Our Rust-to-Zig Rewrite Is Going

#322

Post by antonvs » Sat, Jul 18, 2026, 3:18 AM UTC

patrec wrote: post #275

antonvs wrote: post #33

Earlier quoted context omitted.

I wrote a toy Scheme implementation in OCaml by using the Camplp4 preprocessor. In benchmarks, it was faster than Gambit Scheme, which compiles through C.

Sounds interesting, have you put it online somewhere?

No. I wrote it about 10 years before GitHub existed, and it’s just a toy. All it does is transform core Scheme syntax to Ocaml syntax, converting untyped values in the usual way to a ‘Value’ sum type.

I originally thought it would be slower than the faster Scheme compilers, like Gambit, because of how naive it was, but I was surprised to find that on benchmarks, including compute-heavy ones like fractals and I/O heavy ones like web serving, it outperformed Gambit. That’s really a reflection on Ocaml though, I didn’t do anything special.

If you asked an LLM to do that today, it could probably produce something better for you pretty quickly.

Re: How Our Rust-to-Zig Rewrite Is Going

#323

Post by EPWN3D » Sat, Jul 18, 2026, 4:12 AM UTC

surajrmal wrote: post #102

steveklabnik wrote: post #52

Earlier quoted context omitted.

> 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)

Perhaps the parent meant dynamic linker.

I was thinking a classical linker that e.g. combined sections together after already laying out subsequent sections. That would basically be an memmove. It doesn't necessarily have to be unsafe, but I could see it being implemented that way just to keep things simpler on the rest of the data structures. (Though if you said that that was an indication of incomplete design I'd have a lot of time for that argument.)

Re: How Our Rust-to-Zig Rewrite Is Going

#324

Post by dnautics » Sat, Jul 18, 2026, 5:02 AM UTC

gpm wrote: post #312

dnautics wrote: post #311

Earlier quoted context omitted.

did you miss this part? > planned to be addressed i have in mind a strategy to address all of them. this is a side project, a proof of concept, i have other things going on in my life. i dont chip away at it every week. you make, without any evidence ("Obviously"), an assertion that "it would look like another language". so far if anything applying zig clr would push a user to write more idiomatically ziggy code, awa…

I wish them the best of luck, but I don't expect them to succeed, and unspecified plans don't constitute a demonstration of feasibility. Plenty of people have made plans to solve unsolvable problems in the past, me included. I strongly suspect that that is the case here (or that they're willing to iterate away from zig). The evidence is the amount that rust had to iterate on the underlying language to make the borrow…

do you want a direct description of the plan for async/alias work? hash the globally accessed gid list and if any operation changes retrigger analysis of all functions in the same execution block with the new layout.

i have not had to change the language to accomodate uaf/df/leak analysis (which is not easy). i see no reason why i should have to to get async/alias to work.

unlike rust, as of zig 0.16 async conceptually is abstracted to a userland interface in the stdlib (versus a keyword), which means that its easier to detect, and easier to work into the existing clr system. that means it's either "not doable at all" (unlikely) or is unlikely to need any back and forths to be done with the language

Re: How Our Rust-to-Zig Rewrite Is Going

#325

Post by jibal » Sat, Jul 18, 2026, 12:07 PM UTC

minraws wrote: post #278

samatman wrote: post #220

Earlier quoted context omitted.

Scenario A: A program has a memory vulnerability. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerability, which could even lead to privilege escalation. Scenario B: A program writes machine code in an executable region of memory, and the code has a memory vulnerability. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerab…

How is that a memory safety issue in Rust compiler? What point are we making here. Am I just too dense to understand, is how the hell is that a need unsafe issue? Or anything to do with compilers???

TFA discusses this in detail. The point is memory errors in the generated code. The generated code is an output the compiler. Thus the OP counts these against the compiler--after all, that's his project, those bugs are real, and those bug reports must be dealt with. His point is that the Rust borrow checker doesn't help at all with these bugs, and that matters when weighing the pros and cons of writing the compiler in Rust vs. Zig -- the languages are a wash for that category of error.

I do think this is a bit off, because miscompilations can produce all sorts of errors, not just memory errors, so it doesn't make much sense to categorize them as memory errors -- they are logic errors in the compiler. But the basic idea holds -- the choice of implementation language doesn't matter.

Re: How Our Rust-to-Zig Rewrite Is Going

#326

Post by jibal » Sat, Jul 18, 2026, 12:12 PM UTC

Joker_vD wrote: post #177

steveklabnik wrote: post #55

Earlier quoted context omitted.

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 t…

> Usually this would be done via an interpreter, so I'm not sure that it really requires unsafe either. Well, I personally have written a const-expression evaluator that actually reuses the rest of the compiler: it compiles the expression in the current environment with some specific adjustments to the codegen settings, launches the temporary executable and gathers its output... frankly, it's more hassle than it's wo…

It depends somewhat on the complexity of the language.

Nim uses an interpreter but Nimony, which is destined to becomes Nim 3.0, uses your approach. It will be interesting to how hassles and performance play out there and whether they keep the compile-and-run approach or go back to an interpreter.

Re: How Our Rust-to-Zig Rewrite Is Going

#327

Post by onlyrealcuzzo » Sat, Jul 18, 2026, 2:24 PM UTC

dnautics wrote: post #319

onlyrealcuzzo wrote: post #315

Earlier quoted context omitted.

> zig in particular is easy (disclaimer: i think, i haven't implemented it yet) I guess it's "easy" compared to other languages - but if you think it's "easy", we have different definitions of "easy". You could implement it, but it would look like efforts in Rust to get SPARK-like safety, and SPARK itself. It will essentially be a different language. You will not be able to work seamlessly with any regular Zig code.…

> You will not be able to work seamlessly with any regular Zig code. That may or may not be a problem if you're willing to assume you can just use it all unsafely and it works enough that things are fine. that may be true, but it seems "not". to date, all of the patterns in zig-clr nudge you towards idiomatic zig and not away from it. i run tests on not-my-code (an unaltered version of an existing zig project -- you…

By all means - reach out when it's ready and I'll give it a test.

I'm highly skeptical you can get it to work. If it was easy and optional and non-invasive and actually worked - the Zig team would almost certainly build it.

But, even if it just mostly works - that would still be very useful if it's non invasive.

Re: How Our Rust-to-Zig Rewrite Is Going

#328

Post by niclas-ahden » Sat, Jul 18, 2026, 3:01 PM UTC

bbkane wrote: post #168

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. An…

>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!

Re: How Our Rust-to-Zig Rewrite Is Going

#329

Post by em-bee » Sat, Jul 18, 2026, 3:05 PM UTC

bsder wrote: post #188

em-bee wrote: post #140

Earlier quoted context omitted.

languages ideally should not have breaking changes ever. on the other hand, a language with frequent breaking changes should not be considered production ready. people are of course free to live on the edge, and if someone decided that zig is good enough and they are not bothered by breaking changes then they are free to use it for their production system, but that doesn't mean it's ready for everyone. so i prefer th…

> languages ideally should not have breaking changes ever. I disagree MIGHTILY . This is how you wind up with C++ and Java. Languages need to be able to remove features to stay coherent. Occasionally, you get things wrong, it takes time to figure that out, and that's just the way life is.

i'd like to add, there are many things that can be criticized on C++ or java. but language stability is not one of them. in fact i believe language stability is one of the things that keeps both languages an ongoing success.

Re: How Our Rust-to-Zig Rewrite Is Going

#330

Post by dnautics » Sat, Jul 18, 2026, 3:13 PM UTC

onlyrealcuzzo wrote: post #327

dnautics wrote: post #319

Earlier quoted context omitted.

> You will not be able to work seamlessly with any regular Zig code. That may or may not be a problem if you're willing to assume you can just use it all unsafely and it works enough that things are fine. that may be true, but it seems "not". to date, all of the patterns in zig-clr nudge you towards idiomatic zig and not away from it. i run tests on not-my-code (an unaltered version of an existing zig project -- you…

By all means - reach out when it's ready and I'll give it a test. I'm highly skeptical you can get it to work. If it was easy and optional and non-invasive and actually worked - the Zig team would almost certainly build it. But, even if it just mostly works - that would still be very useful if it's non invasive.

> the Zig team would almost certainly build it

1. It's a small team.

2. The zig team is parsimonious about what they do and don't build. For example, they did not work on the language server, rather punting it to the community.

3. That you can do this with the zig compiler is a happy accident. The team was not designing towards this possibility, it's not really a part of the core zig ethos (and that's fine).

4. You certainly cannot do things exactly the way that rust does it without changing the language; because the rust conversation has sucked all of the air out of the discourse around safety, you really do have to make a paradigm shift away from "tagged ownership" to "data dependency tracking with ownership agnosticism" to do it with zig.