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

101–110 of 412 posts

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

#101

Post by bilekas »

qw3rty01 wrote: post #57
Galanwe wrote: post #33

Earlier quoted context omitted.

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

This is exactly the opposite of what he’s saying, using Arc everywhere is hacking around the borrow checker , a seasoned rust developer will structure their code in a way that works with the borrow checker; Arc has a very specific use case and a seasoned rust developer will rarely use it

This is something I have noticed while I'm by no means seasoned enough to consider myself even a mid level, some of my colleagues are and what they tend to do it plan ahead much better or pedantically, as they put it, the worst thing you will end up doing it's trying to change an architectural decision later on.

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

#102

Post by zem »

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.

that is the precise point at which the article lost me. ironically it's often good programmers who don't "get" the benefit of building memory management and discipline into the language, rather than leaving it to be a cognitive burden on every programmer.

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

#103

Post by tleyden5iwx »

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…

I don't think like a C programmer, my problem is that I think like a Java/Python/Go programmer, and I'm spoiled by getting used to having a garbage collector always running behind me cleaning up my memory poops.

Even though Rust can end up with some ugly/crazy code, I love it overall because I can feel pretty safe that I'm not going to create hard-to-find memory errors.

Sure, I can (and do) write code that causes my (rust) app to crash, but so far they've all been super trivial errors to debug and fix.

I haven't tried Zig yet though. Does it give me all the same compile time memory usage guarantees?

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

#104

Post by mattwilsonn888 »

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 developer ergonomics but produces memory safe software, whereas Zig has good developer ergonomics and allows me to produce memory safe software with a bit of discipline.

The Rust community should be upfront about this tradeoff - it's a universal tradeoff, that is: Safety is less ergonomic. It's true when you ride a skateboard with a helmet on, it's true when you program, it's true for sex.

Instead you see a lot of arguments with anecdotal or indeterminate language. "Most people [that I talk to] don't seem to have much trouble unless they're less experienced."

It's an amazing piece of rhetoric. In one sentence the ergonomic argument has been dismissed by denying subjectivity exists or matters and then implying that those who disagree are stupid.

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

#105

Post by packetlost »

vlovich123 wrote: post #99
packetlost wrote: post #92

Earlier quoted context omitted.

Arc is all over the place if you're writing async code unfortunately. IMO Tokio using a work-stealing threaded scheduler by default and peppering literally everything with Send + Sync constraints was a huge misstep.

Arc + work stealing scheduler is common. But work stealing schedulers are common (eg libdispatch popularized it). I believe the only alternative is thread-per core but they’re not very common/popular. For what it’s worth zig would look very similar except their novel injectable I/O syntax isn’t compatible with work stealing. Even then, I’d agree that while Arc is used in lots of places in work stealing runtimes, I di…

Being possible with minimal effort doesn't really preclude it from it not being the default. The issue I have is huge portions of Tokio's (and other async libs) API have a Send + Sync constraint that destroy the benefit of LocalSet / spawn_local. You can't build and application with the specialized thread-per core or single-threaded runtime thing if you wanted to because of pervasive incidental complexity.

I don't care that they have a good work-stealing event loop, I care that it's the default and their APIs all expect the work-stealing implementation and unnecessarily constrain cases where you don't use that implementation. It's frustrating and I go out of my way to avoid Tokio because of it.

Edit: the issues are in Axum, not the core Tokio API. Other libs have this problem too due to aforementioned defaults.

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

#106

Post by levkk »

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…

Definitely not. Arc is for immutable (or sync, e.g. atomics, mutexes) data, while borrow checker protects against concurrent mutations. I think you meant Arc> everywhere, but that code smells immediately and seasoned Rust devs don't do that.

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

#107

Post by johncolanduoni »

kllrnohj wrote: post #62
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 bac…

I think this focus cuts both ways though - most "one & done" CLI tools will not be bottlenecked by a GC. Many are so performance insensitive that Python is totally fine, and for most of the rest the performance envelope of Go is more than enough. Why would I reach for Rust or Zig for these? "I like C, Zig is like C" is a totally acceptable reason, but then this whole article is preaching to the choir.

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

#108

Post by jasonpeacock »

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…

> 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 extra tools to try and achieve the same result as Rust.

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

#109

Post by anon-3988 »

i am sorry but how does point 1 and point 2 for safety work together? You don't want the program to corrupt your program but also does not want to immediately crash the moment some invariant is not being held?

> Compile-time only: The borrow checker cannot fix logic bugs, prevent silent corruption, or make your CLI behave predictably. It only ensures memory rules are followed.

Also not really true from my experience. There have been plenty of times where the borrow checker is a MASSIVE help in multithreaded context.

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

#110

Post by Aurornis »

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…

> thus effectively switching to automatic garbage collection

Arc isn't really garbage collection. It's like a reference counted smart pointer like C++ has shared_ptr.

If you drop an Arc and it's the last reference to the underlying object, it gets dropped deterministically.

Garbage collection generally refers to more complex systems that periodically identify and free unused objects in a less deterministic manner.

Post reply on HN