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

#141

Post by qzw » Tue, Sep 23, 2025, 4:41 PM UTC

hu3 wrote: post #90

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 did some quick search, not sure if this supports or denies your point: - 151 instances of "Arc https://github.com/search?q=repo%3Aservo%2Fservo+Arc%3C&type... - 5 instances of "Arc https://github.com/search?q=repo%3Arusoto%2Frusoto%20Arc%3C&... - 0 instances for "Arc https://github.com/search?q=repo%3Acgag%2Floc%20Arc%3C&type=...

Appreciate the real numbers. Would be interesting to see what percentage of data structures contain Arc, but that's a lot more work.

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

#142

Post by andrewshadura » Tue, Sep 23, 2025, 4:42 PM UTC

Does it?

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

#143

Post by hansvm » Tue, Sep 23, 2025, 4:44 PM UTC

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…

> Regardless, code that doesn't use unsafe can't have two threads concurrently writing the same memory.

It's a bit messier than that. Basically the only concurrency-related bug I ever actually want help with from the compiler is memory ordering issues. Rust chose to make those particular racey memory writes safe instead of unsafe.

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

#144

Post by aidenn0 » Tue, Sep 23, 2025, 4:45 PM UTC

carodgers wrote: post #140

This really misses a major point. If you write something in Zig, you can have some confidence in the stability of the program, if you trust yourself as a developer. If someone else writes something else in Zig, you have to live with the possibility that they have not been as responsible as you would have preferred.

Indeed. The other day I was messing around with making various associative data structures in Zig.

I stole someone else's benchmark to use, and at one point I ran into seriously buggy behavior on strings (but not integers) that wasn't caught at the point where it happened early even with -Odebug.

Turns out the benchmark was freeing the strings before it finished performing all of the operations on the data structure. That's the sort of thing that Rust makes nearly impossible, but Zig didn't catch at all.

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

#145

Post by pjmlp » Tue, Sep 23, 2025, 4:46 PM UTC

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…

As I mention elsewhere, C crowd didn't call languages like Pascal and Modula-2 programming with straightjacket for no reason.

Turns out not wearing that helmet, and continously falling down for 40 years at the skate park has its price.

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

#146

Post by travisgriggs » Tue, Sep 23, 2025, 4:47 PM UTC

> memory safety is one puzzle piece of overall software safety

So this. We currently spent about a month carefully instrumenting and coming to understand a subtle bug in our distributed radio network. This all runs on bare metal C (samd21 chips). Because timing, and hundreds of little processors, and radios were all involved, it was a pita to surface what the issue was. It was algorithmic. Not a memory problem. Writing this in rust or zig (instead of straight C) would not have fixed this problem.

I’d like to consider doing next generations of this product in zig or rust. I’m not opposed. I like the extra tools to make the product better. But they’re a small part of the picture in writing good software. The borrow checker may improve your code, it doesn’t guarantee successful software.

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

#147

Post by vlovich123 » Tue, Sep 23, 2025, 4:48 PM UTC

packetlost wrote: post #105

vlovich123 wrote: post #99

Earlier quoted context omitted.

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

Single-threaded runtime doesn't require Send+Sync for spawned futures. AFAIK Tokio doesn't have a thread-per-core backend and as a sibling intimated you could build it yourself (or use something more suited for thread-per-core like Monoio or Glommio).

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

#148

Post by Imustaskforhelp » Tue, Sep 23, 2025, 4:48 PM UTC

dayvster wrote: post #14

Imustaskforhelp wrote: post #7

What are your thoughts on nim, odin and v-lang, D-lang? I feel like I am most interested about nim given how easy it was to pick up and how interoperable it is with C and it has a garbage collector and can change it which seems to be great for someone like me who doesn't want to worry about manual memory management right now but maybe if it becomes a bottleneck later, I can atleast fix it without worrying too much..

I have not given any of those 3 a fair enough shot just yet to make a balanced and objective decision. Out of all of them from what little I know and my very superficial knowledge Odin seems the most appealing to me, it's primary use case from what I know is game development I feel like that could easily pivot into native desktop application development was tempted to make a couple of those in odin in the past but ne…

I am a big fan of golang lol. Golang might be the language that I can love the most, portable, easy to write, stdlib that's goated, fast to compile with, and a great ecosystem!

But I like nim in the sense that I feel sometimes in golang that I can't change its GC and so although I do know that for most things it wouldn't be a breaker.

but still, I sometimes feel like I should've somewhat freedom to add memory management later without restarting from scratch or something y'know?

Golang is absolutely goated. This was why I also recommended V-lang, V-lang is really similar to golang except it can have memory management...

They themselves say that on the website that IIRC if you know golang, you know 70% V-lang

I genuinely prefer golang over everything but I still like nim/ V-lang too as fun languages as I feel like their ecosystem isn't that good even though I know that yes they can interop with C but still...

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

#149

Post by packetlost » Tue, Sep 23, 2025, 4:48 PM UTC

Arnavion wrote: post #128

packetlost wrote: post #105

Earlier quoted context omitted.

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

>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. [...] It's frustrating and I go out of my way to avoid Tokio because of it. At $dayjob we have built a large codebase (high-throughput message broker) using the thread-per-core model with tokio (ie one worker thread per CPU, pinned to that CPU, driving a s…

I might be misremembering and the overbearing constraints might be in Axum (which is still a Tokio project). External libs are a huge problem in this area in general, yeah.

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

#150

Post by reddit_clone » Tue, Sep 23, 2025, 4:50 PM UTC

tayo42 wrote: post #94

cestith wrote: post #80

Earlier quoted context omitted.

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.

Indeed, but it is considered a strength by Go enthusiasts. Not being able to build clever abstractions is a feature.

So is the error handling boilerplate.