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

361–370 of 412 posts

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

#361

Post by junon »

mattwilsonn888 wrote: post #104
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…

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…

Writing rust fulltime for my personal projects, I have to disagree that Rust isn't ergonomic.

In fact, I find it more ergonomic than any other language I ever work with. I'm consistently more productive with it than even scripting languages.

Getting tired of this quip being asserted as fact. Ergonomics are subjective; memory safety is not.

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

#362

Post by ViewTrick1002 »

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…

> 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.

How else would you safely share data in multi-threaded code? Which is the only reason to use Atomic reference counts.

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

#363

Post by vanderZwan »

tptacek wrote: post #300
blacksmith_tb wrote: post #281

Earlier quoted context omitted.

I think the implication is something like "overwork / fraying morale from long hours means shipping more bugs".

The point of memory-safe languages is to foreclose on a set of particularly nasty bugs, regardless of how frayed engineer morale is.

I'm pretty sure that in an overworked environment the engineers would reach for Rust's unsafe mode pretty quickly because they're too tired to make sense of the borrow checker.

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

#364

Post by ViewTrick1002 »

jmull wrote: post #248
estebank wrote: post #211

Earlier quoted context omitted.

> But it doesn't address all kinds of other logic errors/bugs. It's like closing one door to the barn, but there are six more still wide open. Could you point at some language features that exist in other languages that Rust doesn't have that help with logic errors? Sum types + exhaustive pattern matching is one of the features that Rust does have that helps a lot to address logic errors. Immutability by default, syn…

IMO, simplicity is the number one feature. The developer should spend their attention on the problem space as much as possible, and on the solution space as little as possible. There's a complexity cost to adding features, and while each one may make sense on its own, in aggregate they may collectively burden the developer with too much complexity.

The question is, what is simplicity?

Go tries to hide the issues, until a data loss happens because it has had trouble dealing with non-UTF8 filenames and Strings are by convention UTF8 but not truly and some functions expect UTF8 while others can work with any collection of bytes.

https://blog.habets.se/2025/07/Go-is-still-not-good.html

Or the Go time library which is a monster of special cases after they realized they needed monotonic clocks [1] but had to squeeze it into the existing API.

https://pkg.go.dev/time

Rust is on the other end of the spectrum. Explicit over implicit, but you can implicitly assume stuff works by panicking on these unexpected errors. Making the problem easy to fix if you stumble upon it after years of added cruft and changing requirements.

[1]: https://github.com/golang/go/issues/12914

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

#365

Post by zelphirkalt »

6P58r3MXJSLi wrote: post #352
zanellato19 wrote: post #249

Earlier quoted context omitted.

>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. Can you provide examples for it? Because it honestly doesn't seem like it has ever been done.

postfix sqlite billions of installations and relatively few incidents

Few incidents != memory safe

Few incidents != not badly exploitable

Few incidents != no more undiscovered safety bugs/issues

I don't think your examples quite cut it.

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

#366

Post by zelphirkalt »

dayvster wrote: post #276
zanellato19 wrote: post #265

Earlier quoted context omitted.

I wasn't trying to be a dick, I am saying that my experience is that no big C program is ever safe. You replied that it is possible and I asked for an example. Providing a small script to prove that big C programs are safe isn't enough.

Making a broad statement like there has never been a memory safe C program is a bit of a dickish thing to say. especially when you phrase it as > Can you provide examples for it? Because it honestly doesn't seem like it has ever been done. it comes off as pedantic and arrogant. It obviously is possible to write memory safe software in C and obviously it has been done before otherwise we would not be currently communi…

It's not dickish, and it's weird you seem to feel attacked/offended by that. It is a realistic conclusion, that we have come to over the course of decades of C usage. One could call it wisdom or collective learning.

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

#367

Post by player1234 »

junon wrote: post #361
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…

Writing rust fulltime for my personal projects, I have to disagree that Rust isn't ergonomic. In fact, I find it more ergonomic than any other language I ever work with. I'm consistently more productive with it than even scripting languages. Getting tired of this quip being asserted as fact. Ergonomics are subjective; memory safety is not.

[dead]

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

#368

Post by zorked »

tialaramex wrote: post #77
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 I like the fact that "fighting the borrow checker" is an idea from the period when the borrowck only understood purely lexical lifetimes. So you have to fight to explain why the thing you wrote, which is obviously correct, is in fact correct. That's already ancient history by the time I learned Rust in 2021. But, this idea that Rust will mean "fighti…

Ah, thanks for the historical take. I learned Rust recently. I like it. I never fought the borrow checker. I was sometimes happily protected by the borrow checker. I never understood what people were talking about.

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

#369

Post by ajross »

simonask wrote: post #342
ajross wrote: post #323

Earlier quoted context omitted.

> In the C/C++/Zig code, you would add the second concurrent access, and then start fixing things up and restructuring things Well, sure, which in practice means throwing a lock around it. I mean, I get it. There's a category of bugs that happen in real code. Rust chooses some categories of bugs (certainly not all of them) to construct walls around and forces code into idioms that can be provably correct for at least…

This is true out of the box - Rust isn't magical, and it can't fix all your bugs for you. But it does make its own tools available to you, an API designer. Lifetimes are available to you without ever making any actual references, and the Send/Sync traits are available to you without constructing any standard synchronization mechanism. You can construct something like `PhantomData ` to express invariants like "while t…

Again though, I don't see a lot of value there. You seem to be implicitly repeating the prior that rust prevents race conditions, and it emphatically does not. It detects and prevents concurrent unlocked[1] access to a single memory location, which is not the same thing. Real races are much more complicated than that and happen in the semantic space of the application, not the memory details (again, think of email lockfiles as a classic race that has nothing to do with memory at all).

[1] Though with overhead. It's tends not to be possible in safe rust to get it to generate code that looks like a pthread_mutex critical section. This again is one of my peeves, you do dangerous shared memory concurrency for performance!

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

#370

Post by SoraNoTenshi »

Ar-Curunir wrote: post #153
SoraNoTenshi wrote: post #125

Earlier quoted context omitted.

It also drives me insane when i dump the problems i have with Rust about this exact issue, that i usually have to restructure my code to satisfy the compilers needs, and they come at me with the "Skill Issue" club... I honestly don't even know what to respond to that, but it's kind of weird to me to honestly think that you'd need essentially a "PhD" in order to use a tool...

Not saying that Rust is necessarily easy to pick up, but hundreds of thousands of people use Rust without a PhD in any subject.

It is of course an exaggeration, but that's what is somewhat annoying to me. But dismissing this point by just saying me "get better" after literally years of using Rust is a bit of a weak point, or am i in the wrong here?

And it's not even that i dislike the language, but this is evangelism to just dismiss the point of my argument with "skill issue". A tool isn't supposed to be difficult, it should help you in whatever you're trying to achieve, not making it more difficult.

Post reply on HN