Seems like Rust unsafe could be improved without changing the language design.
How Our Rust-to-Zig Rewrite Is Going
271–280 of 336 posts
Re: How Our Rust-to-Zig Rewrite Is Going
#272Re: How Our Rust-to-Zig Rewrite Is Going
#273Earlier quoted context omitted.
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.
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...
Can selectively turn off the borrow check for dev builds?
Re: How Our Rust-to-Zig Rewrite Is Going
#274Re: How Our Rust-to-Zig Rewrite Is Going
#275Earlier quoted context omitted.
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.
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?
Re: How Our Rust-to-Zig Rewrite Is Going
#276Earlier quoted context omitted.
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 a…
There's a material difference on one taking risks for oneself and one taking risks where the brunt of the consequences fall on others.
You mean like driving a car?
Re: How Our Rust-to-Zig Rewrite Is Going
#277Earlier quoted context omitted.
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.09…
This paper uses models that are over a year old at this point. Many people didn't believe that LLMs were worth using for programming until 6 months after that, and now again this week we've had another huge leap in abilities. This is beyond the other issues with the methodology of this study. For example, their Rust code was created by asking Deepseek to port their C++ code, not having it try and write Rust itself.
From what I am seeing in big corp, with low code/no code tooling, coupled with agentic orchestration, for many scenarios the actual programming language will become irrelevant.
Sure the programming platform still needs to be programming in something, but everything else on top will migrate to such tools.
This might not come to all corners of programming, but in the domain of orchestrating SaaS products, with MCP tools replacing classical microservices, it is getting there already in 2026.
Re: How Our Rust-to-Zig Rewrite Is Going
#278Earlier quoted context omitted.
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 a…
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???
Re: How Our Rust-to-Zig Rewrite Is Going
#279Zig 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.
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.
Re: How Our Rust-to-Zig Rewrite Is Going
#280I 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 machin…
> 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 ther…
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?