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

91–100 of 412 posts

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

#91

Post by Ygg2 »

dayvster wrote: post #41
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 No true scotsman would ever be confused by the borrow checker. i've seen plenty of rust projects open source and otherwise that utilise Arc heavily or use clone and/or copy all over the place.

> > Seasoned Rust coders don’t spend time fighting the borrow checker

> No true scotsman would ever be confused by the borrow checker.

I'd take that No true scotsman over the "Real C programmers write code without CVE" for $5000.

Also you are strawmanning the argument. GP said, "As a seasoned veteran of Rust you learn to think like the borrow checkers." vs "Real Rust programmers were born with knowledge of borrow checker".

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

#92

Post by packetlost »

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

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.

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

#93

Post by christophilus »

nicoburns wrote: post #38
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…

100% I came to Rust from a primarily JavaScript/TypeScript background, and most of the idioms and approaches I was used to using translated directly into Rust.

Including pulling in hundreds of dependencies, unfortunately.

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

#94

Post by tayo42 »

cestith wrote: post #80
kllrnohj wrote: post #62

Earlier quoted context omitted.

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

Do you know any other languages that tend to be safer than C and suitable for CLI tools but without the borrow checker? Over many years I’ve seen a lot in C++, Go, Perl, Python, Ruby, Pascal, various shells, assembly, Java, and some in Haxe, Ada, Lisp, Scheme, Julia, forms of Basic, and recently JavaScript or Typescript. Most of those are more memory safe than C. None of them have the borrow checker. This leaves me w…

With how easily go creates statically compiled binaries and cross compiles I think that might be best language for cli tools. Unfortunate becasue it's annoyingly unexpressive.

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

#98

Post by ChadNauseam »

swiftcoder wrote: post #45
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…

I don't think there are any Arcs in my codebase (apart from a couple of regrettable ones needed to interface with Javascript callbacks in WASM - this is more a WASM problem than a rust problem).

haha, I was about to leave the exact same comment. how are you finding wasm? I’ve been feeling like rust+react is my new favorite tech stack

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

#99

Post by vlovich123 »

packetlost wrote: post #92
qw3rty01 wrote: post #57

Earlier quoted context omitted.

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

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 disagree that it’s used everywhere or that you can really do anything else if you want to leverage all your cores with minimum effort and not having to build your application specialized to deal with that.

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

#100

Post by vlovich123 »

dev_l1x_be wrote: post #43
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 can't remember the last time I had any problem with the borrow checker. The junior solution is .clone(), better one is & (reference) and if you really need you can start to use . There is a mild annoyance with which function consumes what and the LLM era really helped with this. My beef is sometimes with the ways traits are implemented or how AWS implemented Errors for the their library that is just pure madness.

> The junior solution is .clone()

I really hope it’s an Rc/Arc that you’re cloning. Just deep cloning the value to get ownership is dangerous when you’re doing it blindly.

Post reply on HN