How Our Rust-to-Zig Rewrite Is Going

Re:How Our Rust-to-Zig Rewrite Is Going by minraws on Thursday July 16, 2026 @12:53PM (#48937037)

I would like to understand this more,

> rustc emits machine code and then cargo immediately executes it, there's the same opportunity for end user memory being corrupted (due to miscompilation) as if rustc and cargo shared a code base.

Cause this hasn't been true for me or for anyone maybe your definition of memory being corrupted is the not same as mine.

I am not even sure what you are trying to prove with this.

I appreciate the time and effort in building stuff like Roc I don't use it but this comment and the article feel like...

Oh some guy said Zig not nice because memory safety so here, a post why memory safety doesn't exist because we have to do memory unsafe things sometimes and so everything is memory unsafe already, so maybe it doesn't matter.

I get the energy that we are going for seeing useless claims and wanting to push back but I think the article deserves a clearer part 2 where you elaborate on your thoughts about stuff maybe even get it peer reviewed a bit before posting or maybe don't I guess we could use more raw thoughts in the post AI age.

Either way I appreciate someone trying to put forward their own thoughts and explain problems with a different perspective.

[ Parent | on HN ]

Re:How Our Rust-to-Zig Rewrite Is Going by samatman on Thursday July 16, 2026 @06:11PM (#48940942)

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 vulnerability, which could even lead to privilege escalation.

Scenario C: A program write machine code to disk, which is then read into memory and executed. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerability, which could even lead to privilege escalation.

[ Parent | on HN ]

Re:How Our Rust-to-Zig Rewrite Is Going by dwattttt on Thursday July 16, 2026 @11:36PM (#48943101)

Or scenario D:

A text editor stores a URL in a location on disk, and another component then fetches and executes that with its current privileges.

[ Parent | on HN ]

Re:How Our Rust-to-Zig Rewrite Is Going by fragmede on Friday July 17, 2026 @12:37AM (#48943381)

Or in this day and age, that component is an AI agent, and it executes with the things stored in its memory, and is abused into exfiltrating data.

[ Parent | on HN ]

Re:How Our Rust-to-Zig Rewrite Is Going by minraws on Friday July 17, 2026 @02:59AM (#48944155)

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

[ Parent | on HN ]

Re:How Our Rust-to-Zig Rewrite Is Going by jibal on Saturday July 18, 2026 @08:07AM (#48957343)

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.

[ Parent | on HN ]