Last week, a developer named Simo Arpe posted something on Hacker News that should have been boring. It was a terminal UI for Git, called Ziggity, written in Zig. He admitted it was inspired by lazygit, which he used daily. He listed two reasons for building it: improving a few areas of lazygit for his own workflow, and — well, because he wanted to learn Zig.
That second reason is the one that should make you stop scrolling.
We’ve all seen this pattern. A new language emerges — Rust, Go, Zig, Odin, Nim, pick your poison — and within weeks, someone has rewritten htop, fzf, ripgrep, or lazygit in it. The GitHub README always says the same thing: “faster, safer, smaller binary.” But that’s not the whole truth.
Every rewrite is a love letter to a language, not a bug fix to a tool.
Let me be clear: I love Simo’s work. Ziggity looks solid. But when I see the fifth clone of a terminal file manager in a language that has 0.1% market share, I have to ask: Who is this for? Not for the user. The user already has a perfectly good tool in Go. It’s for the developer. For the deep, primal satisfaction of scratching your own itch with a shiny new hammer.
You’ve probably felt it too. The thrill of building something from absolute scratch — no bloated dependencies, no npm install, just you and the compiler. The binary comes out at 800KB. You feel like a god. The problem is that this feeling has a cost: fragmentation.
When every enthusiast rewrites lazygit in C, Zig, Rust, and Haskell, we end up with four half-baked tools instead of one mature one. The ecosystem doesn’t get better. It just gets busier. And the real users — the ones who just want to commit and push — have to learn a new keybinding every six months.
I’m not saying stop learning languages. I’m saying be honest about the motivation. The tension between chasing ultimate performance (Zig) and preserving developer ergonomics (Go) is real. But most of the time, the rewrite isn’t about performance. It’s about philosophy. It’s about the desire to build something pure in a world of corporate abstractions.
The best developer tool is the one that makes you forget you’re using a tool. Ziggity might be that for Simo. But for the rest of us, lazygit — written in Go, with 50,000 GitHub stars — already is. That’s not a failure of Zig. It’s a success of the original.
So next time you see a “Rewrite in $NEW_LANG” announcement, ask yourself: is this solving a real problem, or is it just a developer’s passion project masquerading as innovation? Both are valid. But only one of them deserves your attention as a user.
If you’re the developer, go ahead and build it. You’ll learn a ton. But don’t pretend it’s for the community. Do it for yourself. And then — maybe — keep it as a personal side project rather than flooding the open-source marketplace with yet another half-finished clone.
FAQ
Q: Isn't Zig objectively better than Go for system tools?
A: For certain low-level tasks, yes. But 'better' depends on what you optimize for. Lazygit's main bottleneck is not CPU but human interaction latency. Go's goroutines and garbage collector handle that perfectly. Zig's manual memory management adds complexity without user-facing benefit in this use case.
Q: So should developers stop learning new languages by building projects?
A: Absolutely not. Building projects is the best way to learn. But be honest about the goal. Don't frame your learning project as a superior alternative to an established tool. Release it, tag it as experimental, and let users decide. The problem is not learning — it's marketing a rewrite as a necessary upgrade.
Q: What's the real reason people rewrite tools in new languages?
A: It's a mix of genuine technical curiosity, the joy of building from scratch, and a desire to prove the language's merits. Often it's also a reaction to frustration with the existing language's ecosystem — even if that frustration isn't relevant to the end user. The rewrite is more about the developer's relationship with the tool than the tool itself.