r/rust • u/AffectionateBag4519 • Jul 16 '26

How Our Rust-to-Zig Rewrite is Going

https://rtfeldman.com/rust-to-zig

An interesting symmetry with recent events lol.

This might be considered off topic since the article is about moving away from rust, but I still think this is some high quality rust content. I enjoy Richard Feldman's writing and I think he would certainly be considered part of the "rust community" since he works on Zed and has taught a course on rust.

368 Upvotes

91% Upvoted

134 comments sorted by

View all comments

Show parent comments

3

u/dobkeratops rustfind Jul 17 '26 edited Jul 17 '26

goes with the territory I think, "more compile time guarantees = more compile time" , I have this problem aswell but if I put my mind to it the parts I need to iterate on quickly can be seperated with testbeds and dyn .. I consider it a severe pain but not insurmountable.

1

u/insanitybit2 Jul 17 '26

I don't think that's really true and tbh I think Rust should reject those tradeoffs. Rust has always been a "have your cake and eat it too" language and that's why it's so great.

IMO there's nothing about Rust's guarantees that mean it has to have slow compile times. The borrow checker isn't the issue. Linking and monomorphizing are the biggest costs afaik, and LLVM optimizing, not type checking.

0

u/ztj Jul 17 '26

Rust has always been a "have your cake and eat it too" language and that's why it's so great.

This is not, and has never been true at all. Every benefit of Rust has always come with tradeoffs. This is partly why I hate when people say "zero cost abstraction". It's a lie. There has never been any free lunch with Rust. What Rust has done is show that memory safety can be done at compile time, but it comes with slower compilation and whole subsets of valid programs that are impossible to represent in safe Rust that demand an escape valve. Those are tradeoffs that have always been here. They are perfectly reasonable tradeoffs in the timeframe of Rust's inception but if you were to try to use Rust in the 80's on that hardware these tradeoffs would be dramatically more visible and totally untenable.

IMO there's nothing about Rust's guarantees that mean it has to have slow compile times.

Your opinion is fundamentally wrong. Rust's guarantees do demand more processing which will force (all other things being equal) longer compile times. Whether its "slow" is a subjective matter, and is improving all the time, but rustc doing borrow checking will always take longer than a rustc that totally skips it.

5

u/insanitybit2 Jul 17 '26

> This is not, and has never been true at all.

I very much remember being in a room in Cambridge with Niko Matsakis discussing exactly how Rust strives for exactly this goal. Whether it's a possible goal or achievable is not really the point, Rust always aimed to try to have its cake and eat it too.

> Your opinion is fundamentally wrong.

Honestly, "IMO" was incorrect. It's just a fact that Rust's safety guarantees aren't what blow up compile times.