Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Our Rust-to-Zig Rewrite Is Going

rtfeldman.com

Post reply on HN
Print view View original

231–240 of 336 posts

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

#231

Post by jandrewrogers »

sph wrote: post #226
jandrewrogers wrote: post #203

Earlier quoted context omitted.

Sampling bias. Most of the people responding are probably those with a strong opinion because of what they work on. Everyone else is likely relatively indifferent to it. It is a misconception that GCs only affect latency-sensitive systems. High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either. That a GC is adverse to the performanc…

> Maybe systems that are severely I/O bound but is barely a thing these days. Any kind of web service is barely a thing today? Which is what 99% of HN posters are working on, hence my comment. > High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either Games are high-performance throughput-optimized systems that have adopted GC languag…

If you are severely I/O bound it isn't intrinsic, it means your server is badly under-provisioned in the I/O department. Linux on a modern server can push 200 GB/s of I/O. Even if web services were engineered to a standard that could consume that much I/O, which they are not, you would have to be astonishingly wasteful to burn it all.

It is rare to be severely I/O bound because software engineered for I/O performance tends to run out of memory bandwidth first.

Games are not throughput-optimized systems in any conventional sense. They are a canonical example of latency-optimized systems.

I have nothing against GCs, I use them regularly even in performance-sensitive contexts. But too many people understate the adverse impact of GCs on performance contrary to evidence and theory.

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

#232

Post by dnautics »

kibwen wrote: post #224
afdbcreid wrote: post #198

Earlier quoted context omitted.

Hardening is definitely possible, we've had sanitizers in C/C++ for a long time. It's not full memory safety though. Miri is the same. SeL4C is formal verification, and while it can prove memory safety (and much more) it is much more difficult, to the point that you're basically programming in a different language. Ada/SPARK is your best example, and also the example I know the least of, so I won't comment on.

SPARK omits some features of Ada, so it would only reinforce the sentiment that bolting on verifiability after-the-fact is difficult. Expressivity is generally the antithesis of static analysis, and it's very easy and tempting to make a language that is accidentally too expressive to support a given analysis without being required to make breaking changes to reduce expressivity.

i mean in zig-clr it pushes you towards more expressive patterns, for example, making you label pointers as optional if their status is ambiguous

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

#233

Post by Capricorn2481 »

jandrewrogers wrote: post #203
sph wrote: post #167

Earlier quoted context omitted.

I don’t think there’s too many of us on the ‘GC did nothing wrong’ hill. Reading the average HN opinion, it seems everybody is writing high-performance latency-sensitive systems that would implode if a response would take 1 ms longer than normal.

Sampling bias. Most of the people responding are probably those with a strong opinion because of what they work on. Everyone else is likely relatively indifferent to it. It is a misconception that GCs only affect latency-sensitive systems. High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either. That a GC is adverse to the performanc…

> Most of the people responding are probably those with a strong opinion because of what they work on.

I can assure you that's not the case on here. The people working in truly low latency environments are not commenting on GC threads to begin with because it's a non-starter for them. For whatever reason, there is just a chunk of people that eat a lot of FUD around GCs who are working in the exact domains they thrive in.

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

#234

Post by burnt-resistor »

giancarlostoro wrote: post #31

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…

Use sccache.

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

#235

Post by maybebug »

steveklabnik wrote: post #62
narnarpapadaddy wrote: post #53

Earlier quoted context omitted.

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

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

[flagged]

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

#236

Post by maybebug »

steveklabnik wrote: post #94
rtfeldman wrote: post #74

Earlier quoted context omitted.

Also a good point! TIL that Rust and C++ use interpreters for const, although of course that wouldn't work for running tests. Then again, in the specific case of Rust I believe rustc only compiles the tests and then something else like Cargo executes them. Of course, as I noted elsewhere, if rustc emits machine code and then cargo immediately executes it, there's the same opportunity for end user memory being corrupt…

Cool, I'm not sure that people know that we know each other and have some deeper mutual understanding. :) > although of course that wouldn't work for running tests. Why not? Unless you mean in the cross-compilation case, in which yeah, to run the compiled tests you'd need an emulator. > in the specific case of Rust I believe rustc only compiles the tests and then something else like Cargo executes them. It doesn't ha…

[flagged]

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

#237

Post by steveklabnik »

maybebug wrote: post #235
steveklabnik wrote: post #62

Earlier quoted context omitted.

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

[flagged]

Rust's standard library is filled with 'unsafe' because one of the design goals of the standard library was "put stuff that needs a lot of unsafe in it, because the Rust team is more likely to write it correctly than other people." That is of course different in 2026.

> Memory safety is necessary, but not sufficient,

I fully agree!

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

#238

Post by maybebug »

pjmlp wrote: post #86
steveklabnik wrote: post #11

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

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.

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.

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

#239

Post by maybebug »

steveklabnik wrote: post #237
maybebug wrote: post #235

Earlier quoted context omitted.

[flagged]

Rust's standard library is filled with 'unsafe' because one of the design goals of the standard library was "put stuff that needs a lot of unsafe in it, because the Rust team is more likely to write it correctly than other people." That is of course different in 2026. > Memory safety is necessary, but not sufficient, I fully agree!

> I fully agree!

But why then did you conflate safety and memory safety?

> Rust's standard library is filled with 'unsafe' because one of the design goals of the standard library was "put stuff that needs a lot of unsafe in it, because the Rust team is more likely to write it correctly than other people." That is of course different in 2026.

No, there is a lot of unsafe in both Rust's standard library and in non-standard Rust libraries for multiple reasons, in particular performance for both kinds (std and user/non-std) of libraries. Thus, as I pointed out, for Rust, "unsafe" is in practice often needed for performance in Rust.

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

#240

Post by nvme0n1p1 »

inigyou wrote: post #210
nvme0n1p1 wrote: post #163

Earlier quoted context omitted.

Good for what? A hammer is good for driving a nail, but not good for driving a screw. Safe for what? My house is safe for humans, but not safe for tropical birds. Clean enough for what? Our water is clean enough to wash my ass, but not clean enough to wash a telescope mirror. Sorry but life is not a Disney movie where some things are unequivocally good/safe and other things are unequivocally bad/unsafe. There are gra…

What nail? A hammer is good for driving a nail from the hardware store, but not good for driving a finger nail. See? I can play stupid word games too. How tropical are the birds? I'm afraid life isn't a Disney movie where some things are unequivocally tropical/not tropical. How shared is the language? Congratulations on using only two adjectives in your comment besides the ones you're complaining about, but two is gr…

You're just doing the same thing and further proving my point. Thanks, I guess?
Post reply on HN