Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dayvster.com

Post reply on HN
Print view View original

61–70 of 412 posts

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

#61

Post by steveklabnik »

Galanwe wrote: post #33
simonask wrote: post #21

The benefit of Zig seems to be that it allows you to keep thinking like a C programmer. That may be great, but to a certain extent it’s also just a question of habit. Seasoned Rust coders don’t spend time fighting the borrow checker - their code is already written in a way that just works. Once you’ve been using Rust for a while, you don’t have to “restructure” your code to please the borrow checker, because you’ve a…

> Seasoned Rust coders don’t spend time fighting the borrow checker My experience is that what makes your statement true, is that _seasoned_ Rust developers just sprinkle `Arc` all over the place, thus effectively switching to automatic garbage collection. Because 1) statically checked memory management is too restrictive for most kinds of non trivial data structures, and 2) the hoops of lifetimes you have to go to t…

The only time I use Arc is wrapping contexts for web handlers.

That doesn’t mean there aren’t other legitimate use cases, but “all the time” is not representative of the code I read or write, personally.

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

#62

Post by kllrnohj »

karmakaze wrote: post #36

I was going to say that it's greatly understating the value of the borrow checker. It guarantees no invalid memory accesses. But then it added: > This means that basically the borrow checker can only catch issues at comptime but it will not fix the underlying issue that is developers misunderstanding memory lifetimes or overcomplicated ownership. The compiler can only enforce the rules you’re trying to follow; it can…

> I don't see why CLI tools are special in any respect.

Because they don't grow large or need a multi-person team. CLI tools tend to be one & done. In other words, it's saying "Zig, like C, doesn't scale well. Use something else for larger, longer lived codebases."

This really comes across in the article's push that Zig treats you like an adult while Rust is a babysitter. This is not unlike the sentiment for Java back in the day. But the reality is that most codebases don't need to be clever and they do need a babysitter.

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

#63

Post by kstenerud »

naikrovek wrote: post #31
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.

are you saying that such understanding isn't enough or that every C programmer who said that didn't understand those things? C and Zig aren't the same. I would wager that syntax differences between languages can help you see things in one language that are much harder to see in another. I'm not saying that Zig or C are good or bad for this, or that one is better than the other in terms of the ease of seeing memory pr…

> are you saying that such understanding isn't enough or that every C programmer who said that didn't understand those things?

Probably both. They're words of hubris.

C and Zig give the appearance of practicality because they allow you to take shortcuts under the assumption that you know what you're doing, whereas Rust does not; it forces you to confront the edge cases in terms of ownership and provenance and lifetime and even some aspects of concurrency right away, and won't compile until you've handled them all.

And it's VERY frustrating when you're first starting because it can feel so needlessly bureaucratic.

But then after awhile it clicks: Ownership is HARD. Lifetimes are HARD. And suddenly when going back to C and friends, you find yourself thinking about these things at the design phase rather than at the debugging phase - and write better, safer code because of it.

And then when you go back to Rust again, you breathe a sigh of relief because you know that these insidious things are impossible to screw up.

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

#64

Post by stonemetal12 »

The fact that your app crashes when you run out of stack is a compiler bug, not a feature. Memory is memory. The fact that languages in the 40s split in it to stack and heap, doesn't make it a foundational mathematical law.

Yes, safety isn't correctness but if you can't even get safety then how are you supposed to get correctness?

For small apps Zig probably is more practical than Rust. Just like hiring an architect and structural engineers for a fence in your back yard is less practical than winging it.

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

#65

Post by scoopdewoop »

dayvster wrote: post #59
scoopdewoop wrote: post #51

This is a really bad take, on par with the "we don't need types" post from last week. The thing I wish we would remember, as developers, is that not all programs need to be so "safe". They really, truly don't. We all grew up loving lots of unsafe software. Star Fox 64, MS Paint, FruityLoops... the sad truth is that developers are so job-pilled and have pager-trauma, so they don't even remember why they got in the gam…

Uh I'm confused, so you think my take is bad because memory safety should not matter ?

I think its a bad take because "Developers are not Idiots" and "be disciplined" are not good arguments. Its just choosing to ignore the problem rust solves.

I am fine with ignoring the problems that rust solves, but not because I'm smart and disciplined. It just fits my use-case of making fast _non-critical_ software. I don't think we should rewrite security and networking stacks in it.

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

#66

Post by dpatterbee »

mr90210 wrote: post #46
dpatterbee wrote: post #30

Earlier quoted context omitted.

I've had at least one instance of Ghostty running on both my work and personal machine continuously since I first got access to the beta last November, and I haven't seen a single segfault in that entire time. When have you seen them?

Google: "wikipedia Evidence of absence" Also, https://github.com/ghostty-org/ghostty/issues?q=segfault

So Ghostty was first publicly released on I think December 27th last year, then 1.0.1, 1.1.0, 1.1.1, and 1.1.2 were released within the next month and a half to fix bugs found by the large influx of users, and there hasn't been a segfault reported since. I would recommend that users who are finding a large number of segfaults should probably report it to the maintainers.

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

#67

Post by kibwen »

Galanwe wrote: post #33
simonask wrote: post #21

The benefit of Zig seems to be that it allows you to keep thinking like a C programmer. That may be great, but to a certain extent it’s also just a question of habit. Seasoned Rust coders don’t spend time fighting the borrow checker - their code is already written in a way that just works. Once you’ve been using Rust for a while, you don’t have to “restructure” your code to please the borrow checker, because you’ve a…

> Seasoned Rust coders don’t spend time fighting the borrow checker My experience is that what makes your statement true, is that _seasoned_ Rust developers just sprinkle `Arc` all over the place, thus effectively switching to automatic garbage collection. Because 1) statically checked memory management is too restrictive for most kinds of non trivial data structures, and 2) the hoops of lifetimes you have to go to t…

> _seasoned_ Rust developers just sprinkle `Arc` all over the place

No, this couldn't be further from the truth.

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

#69

Post by illuminator83 »

Actually, developers are idiots. Everyone is. Some just don't know it or won't admit it.

I once joined a company with a large C/C++ codebase. There I worked with some genuinely expert developers - people who were undeniably smart and deeply experienced. I'm not exaggerating and mean it.

But when I enabled the compiler warnings (which annoyed them) they had disabled and ran a static analyzer over the codebase for the first time, hundreds of classic C bugs popped up: memory leaks, potential heap corruptions, out-of-bounds array accesses, you name it.

And yet, these same people pushed back when I introduced things like libfmt to replace printf, or suggested unique_ptr and vector instead of new and malloc.

I kept hearing:

"People just need to be disciplined allocations. std::unique_ptr has bad performance" "My implementation is more optimized than some std algorithm." "This printf is more readable than that libfmt stuff." etc.

The fact is, developers, especially the smart ones probably, need to be prevented from making avoidable mistakes. You're building software that processes medical data. Or steers a car. Your promise to "pay attention" and "be careful" cannot be the safeguard against catastrophe.

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

#70

Post by dayvster »

scoopdewoop wrote: post #65
dayvster wrote: post #59

Earlier quoted context omitted.

Uh I'm confused, so you think my take is bad because memory safety should not matter ?

I think its a bad take because "Developers are not Idiots" and "be disciplined" are not good arguments. Its just choosing to ignore the problem rust solves. I am fine with ignoring the problems that rust solves, but not because I'm smart and disciplined. It just fits my use-case of making fast _non-critical_ software. I don't think we should rewrite security and networking stacks in it.

Then we're sort of in agreement.

I don't think you need the ritual and complexity that rust brings for small and simple scripts and CLI utilities...

Post reply on HN