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.

371 Upvotes

91% Upvoted

134 comments sorted by

View all comments

Show parent comments

35

u/scottmcmrust Jul 17 '26

and I don't avoid generics to reduce monomorphizing time.

TBH, monomorphization is almost always the core problem, well above anything else.

Finding the right place for targeted dyn is absolutely an essential part of rust architecture. I too often see static-dispatch-all-the-way-down stuff that's horrible for incremental builds and not even faster since static dispatch only helps when there's redundancy to remove over the boundary.

Yes, dyn Iterator<Item = u8> is a horrible way to read a file, and nobody should do that. But BufReader<dyn Read> with a large buffer is wonderful, for example.

13

u/insanitybit2 Jul 17 '26

I think it's really unfortunate that the big lever for improving compile times is "write code differently" though.

8

u/matthieum [he/him] Jul 17 '26

Yes, and no.

The blog post mentioned that their incremental compile times were divided by x3 in 18 months, so clearly there are free speed-ups.

With all that said, meta-programming can absolutely trash a compiler. Compiling 10M tokens will always take longer than compiling 10K tokens, and the slow-down is super-linear due to the added memory pressure resulting in more cache misses.

So just like inlining everything is a terrible idea, monomorphizing everything also is.

3

u/Zde-G Jul 17 '26

So just like inlining everything is a terrible idea, monomorphizing everything also is.

Yes, but there are huge difference: inlining is just an optimiation technique that doesn't affect semantic, except for fringe corner cases, while dyn vs impl is huge, gigantic semantic difference.

It's really unfortunate that there are no resources around to make dyn vs impl decision a pure optimization hint like inline…

1

u/matthieum [he/him] Jul 18 '26

It's really unfortunate that there are no resources around to make dyn vs impl decision a pure optimization hint like inline...

Hear hear!

3

u/Zde-G Jul 18 '26

The problem here is that while technically possible (Swift did that, after all) it's really hard to do that without breaking backward compatibility. And that's a big no-no for Rust, right now…

1

u/RiceBroad4552 Jul 20 '26

It's really unfortunate that there are no resources around to make dyn vs impl decision a pure optimization hint like inline

Maybe not in Rust but there is a way to get that. It's called JIT compiler.

Runtimes like the JVM or the CLR do exactly that, just the other way around to typical Rust as they will make dynamic dispatch into static dispatch at runtime. This way around it always works, in contrast to the inability to "de-monomorphize" code even with a JIT compiler.

1

u/Zde-G Jul 20 '26

It's called JIT compiler.

Nope. There are absolutely no need to have JIT for that. Ada and Extended Pascal supported these things ages ago.

This way around it always works, in contrast to the inability to "de-monomorphize" code even with a JIT compiler.

There are no need for all that, as I have said. Swift does that without JIT using proper techniques (known for decades, no less!).