Zig feels more practical than Rust for real-world CLI tools • Hacker News Board

Re: Zig feels more practical than Rust for real-world CLI tools

#221

Post by johncolanduoni » Tue, Sep 23, 2025, 6:47 PM UTC

pjmlp wrote: post #169

johncolanduoni wrote: post #139

Earlier quoted context omitted.

It makes me sad, because they demonstrated JavaScriptCore is shockingly better than V8 for node-likes. The Typescript compiler (which like basically any non-trivial typechecker is CPU bound) is consistently at least 2x faster with Bun on large projects I've worked on.

When Typescript finishes their Go rewrite that will become irrelevant, and I rather have the compiler from the same people that design the language.

For that example sure, and admittedly the entire JavaScript/TypeScript processing ecosystem is moving in that direction. But the TypeScript compiler is not the only CPU-bound JavaScript out there.

Re: Zig feels more practical than Rust for real-world CLI tools

#222

Post by efnx » Tue, Sep 23, 2025, 6:55 PM UTC

> You’re constantly thinking about lifetimes, ownership, and borrow scopes, even for simple tasks.

As a professional Rust developer, I don’t find I do this. I occasionally think of those things. But I do remember a short adjustment period when I was learning Rust that I would get frustrated by the borrow checker. Of course, that’s it doing its job!

Re: Zig feels more practical than Rust for real-world CLI tools

#223

Post by dmytrish » Tue, Sep 23, 2025, 6:56 PM UTC

jmull wrote: post #129

KingOfCoders wrote: post #5

"All it took was some basic understanding of memory management and a bit of discipline." The words of every C programmer who created a CVE.

I think the problem the practical programmer has with a statement like this is the implication that only certain languages require some basic understanding and a bit of discipline to avoid CVEs. Rust's model has a strict model that effectively prevents certain kinds of logic errors/bugs. So that's good (if you don't mind the price). But it doesn't address all kinds of other logic errors/bugs. It's like closing one do…

Actually, the strong type system is often why people like to write Rust. Because encoding logic invariants in it also helps to prevent logic bugs!

There is a significant crowd of people who don't necessarily love borrow checker, but traits/proper generic types/enums win them over Go/Python. But yes, it takes significant maturity to recognize and know how to use types properly.

Re: Zig feels more practical than Rust for real-world CLI tools

#224

Post by hadlock » Tue, Sep 23, 2025, 6:57 PM UTC

Animats wrote: post #216

He has a point. Backlinks in Rust are too hard. You can do them safely with Rc, Weak, and RefCell, and .borrow(), but it's not trivial. If your program runs for a short time and then exits, arena editing is an option. That seems to be what the author means by "CLI tools". It's the lifetime, not the input format. "Rust is amazing, if you’re building something massive, multithreaded, or long-lived, where compile-time g…

I wrote a physics-accurate flight sim in rust that takes in to account the curvature of the earth and local gravitational fluctuations, it has two tests, one is to fly SFO-Sacramento-Seattle about a 5 hour "flight" at 60 frames per second, the longer one is to fly SFO to Tokyo about 22 hours; it has never once crashed or had a memory leak, it has always worked flawlessly. In 7 years of writing rust I've only ever had a handful of crashes, mostly when writing my own 2d software renderers. The only time I touch C or C++ these days is fixing legacy stuff.

Re: Zig feels more practical than Rust for real-world CLI tools

#225

Post by dpc_01234 » Tue, Sep 23, 2025, 6:58 PM UTC

The title is about CLI tools, then it seems like bunch of cope about borrow-checker-phobia.

I would actually be interested in a honest comparison of a Rust CLI program using clap, duct and some other standard CLI handling libraries with their Zig equivalents.

Show the code side by side, how much boilerplate each requires. Then compare how quickly they compile in debug and release mode, how fast they start, how big the binaries are after stripping, stuff like that.

Re: Zig feels more practical than Rust for real-world CLI tools

#226

Post by kevinrineer » Tue, Sep 23, 2025, 6:59 PM UTC

antoineMoPa wrote: post #40

I also loved Zig when manually typing code, but I increasingly use AI to write my code even in personal projects. In that context, I'd rather use Rust more, since the AI takes care of complex syntax anyway. Also, the rust ecosystem is bigger, so I'd rather stick to this community. > Developers are not Idiots I'm often distracted and AIs are idiots, so a stricter language can keep both me and AIs from doing extra dumb…

> I'm often distracted

I really appreciate this in my role, where I have an office right next to the entrance to the building. I get walk-ins all of the time. When my door is closed, I get knocks on the door all of the time. Both AI and strict languages are great tools in my environment, where focus for me is as abundant as water in a desert.

Re: Zig feels more practical than Rust for real-world CLI tools

#227

Post by pjmlp » Tue, Sep 23, 2025, 7:03 PM UTC

johncolanduoni wrote: post #221

pjmlp wrote: post #169

Earlier quoted context omitted.

When Typescript finishes their Go rewrite that will become irrelevant, and I rather have the compiler from the same people that design the language.

For that example sure, and admittedly the entire JavaScript/TypeScript processing ecosystem is moving in that direction. But the TypeScript compiler is not the only CPU-bound JavaScript out there.

There are plenty of memory safe compiled languages to rewrite that JavaScript into.

Re: Zig feels more practical than Rust for real-world CLI tools

#228

Post by dmytrish » Tue, Sep 23, 2025, 7:06 PM UTC

quotemstr wrote: post #205

I'm still having a hard time understanding who is supposed to use Zig. If I don't need absolute best performance, I can use GC-ed systems like Node, Python, Go, OCaml, or even Java (which starts fast now thanks to Graal AOT) and enjoy both the safety and expressive power of using a high-level language. When I use a GCed language, I don't have to worry about allocation, lifetimes, and so on, and the user gets a plenty…

So far, most of Zig enthusiasts look to me like people who get sugar rush from writing fast native code and are ignorant (i.e. newcomers to system programming) or arrogant (e.g. long time C programmers stubbornly stuck in their ways) enough to think that memory safety is just a question of not writing stupid bugs. Or luddites that think that programs must always be simple enough to get memory safety right.

Re: Zig feels more practical than Rust for real-world CLI tools

#229

Post by dayvster » Tue, Sep 23, 2025, 7:09 PM UTC

K0nserv wrote: post #174

I mostly don't agree with this take. A couple of my quibbles: "Cognitive overhead: You’re constantly thinking about lifetimes, ownership, and borrow scopes, even for simple tasks. A small CLI like my notes tool suddenly feels like juggling hot potatoes." None of this goes away if you are using C or Zig, you just get less help from the compiler. "Developers are not idiots" Even intelligent people will make mistakes be…

this is an excellent example do you mind if I examine it a bit closer and perhaps use it in my article?

Re: Zig feels more practical than Rust for real-world CLI tools

#230

Post by rixed » Tue, Sep 23, 2025, 7:14 PM UTC

jasonpeacock wrote: post #108

mattwilsonn888 wrote: post #104

Earlier quoted context omitted.

As long as the audience accepts the framing that ergonomics doesn't matter because it can't be quantified, the hand-waving exemplified above will confound. "This chair is guaranteed not to collapse out from under you. It might be a little less comfortable and a little heavier, but most athletic people get used to that and don't even notice!" Let's quote the article: > I’d say as it currently stands Rust has poor deve…

> produce memory safe software with a bit of discipline "a bit of discipline" is doing a lot of work here. "Just don't write (memory) bugs!" hasn't produced (memory) safe C, and they've been trying for 50yrs. The best practices have been to bolt on analyzers and strict "best practice" standards to enforce what should be part of the language. You're either writing in Rust, or you're writing in something else + using e…

> "Just don't write (memory) bugs!" hasn't produced (memory) safe C

Yes it did, of course. Maybe it takes years of practice, the assistance of tools (there are many, most very good), but it's always been possible to write memory safe large C programs.

Sure, it's easier to write a robust program in almost every other language. But to state that nobody ever produced a memory safe C program is just wrong. Maybe it was just rethoric for you, but I'm afraid some may read that and think it's a well established fact.