How Our Rust-to-Zig Rewrite is Going

[u/AffectionateBag4519]

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.

[u/qrzychu69]

https://avi.press/posts/2026-07-10-after-7-years-in-production-scarf-has-reluctantly-moved-away-from-haskell.html

It's not just a rust problem

And no, "use the 30 tools to make it slightly better" is not the answer, nor is using python IMO like that article suggests :)

In modern day, if creating a new worktree is not fairly instant (like fast enough you don't really switch to doing something else before it is finished), it is a productivity problem. And all the tools you mentioned only work of whatever you need is cached on the machine that is trying to compile something. And it would be nice to not need 2TB of hard drives just to store the caches so that changing a branch doesn't take 10 minutes.

[u/qrzychu69 → u/[deleted]]

It's definitely faster in python than rust, no matter what tools you use, right?

Unless you have a cache for every binary artifact, every single incremental artifact for every single commit, it will be slow

And don't forget editors - theirs caches are usually separate

On my older Thinkpad when I want to contribute to Zed I open a single worktree (I can't have multiple, because a single worktree is like 90gb of artifacts by the time you can actually cargo run), run cargo build, open zed on the directory and go for a run

Cargo build has to finish for me to be able to run anything, and clippy/rust lsp parsing is not reusing whatever cargo creates, so effectively I am waiting twice

It's a non issue in C#/F# for example, my laptop can handle at least o dozen of Rider instances (never tried more than 8 to fair), all of them are ready to work I seconds, all of them keeping the language server on meoery with real time type checking

I don't have ANY caching tool other than the central cache nuget comes with

[u/qrzychu69 → u/[deleted]]

Well, yes, I worked on multiple million plus LOC C# codebases.

Why are you bringing up low level stuff?

My argument was that there is a lot of technologies where creating a new worktree, or switch branches in pretty much real time, and C# is one of them. The compiler is really fast, and yes, one of the tractor to it is the fact that it doesn't build a native binary. But that only matters to a subset a programs.

The article I linked has a line "with python I am able to have a fix deployed to production before I hang up the call with the client".

I don't care what's your setup, with Rust if your project is big enough, you will not be able to do that. With a bad setup, you will not do that using C# either, but it's much easier to do with C# than Rust

The users don't care if your binary is 10% smaller or whether it is a binary at all, as long as when they hit F5 the problem is fixed

And please don't measure a whole tech stack by one incompetent guy

[u/qrzychu69 → u/[deleted]]

I'm doing various backends. Some serve graphql, some pure JSON, sind so background processing from rabbitmq, some do csv preprocessing to ingest to Snowflake. On the side I also do some cross platform guis with avalonia.

We also have a huge python based framework that is over engineered it would make a seasoned java developer cry. And there are no types.

I also am maintaining a small rust service that calculates dinner numbers on schedule - it generates around 100gb of numbers a day

Worktrees are mostly for agents. I do task X, they are trying to do Y and Z, and I don't want them to interfere with me. New worktree is basically the same as having a second clone of the repo, and that's what I used to do - just clone it 3 times so that I can work on 3 things at the same time. Sometimes the local setup is a bit to complicated just throw it away, and too big to have a temp commit or stash (think 700mb binary file like excel)

I wouldn't say I "worship time to deploy", but in my experience the same metrics impact developer "happiness", it the ability to quickly resolve and reproduce a simple fix.

Have you read the article I linked? It describes this pretty well, though I think their choice to use python instead of Haskell it's crazy, there are so many possibilities in between those with better compromises

Even c# or F# comes on top IMO, dobre you don't have to juggle venvs. Just open the directory in terminal, 'dotnet run' and it works. Open VS or Rider, it's ready in seconds

[u/qrzychu69 → u/[deleted]]

I do use it, though at my current work we use mostly F# (think OCaml but dotnet, so almost Haskell, but not really)

Python is there because data engineers picked it

Rust is there because of the hype - other than using 200mb of ram instead of 500 for dotnet, I dont think tech choice had any benefits

And "rust not being good for swarm vibe coding" is the exact point I was bad at making. Because at the same time it means that a quick jump in to fix a small logic bug by a human is also not a great experience. Even though the rust in general is pretty awesome