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

231–240 of 412 posts

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

#231

Post by illuminator83 »

Cloudef wrote: post #76
illuminator83 wrote: post #69

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…

To be honest, the generated machine code / assembly is often more readable than the actual c++ code in c++ stdlibs. So I can sympathize with the "This printf is more readable than that libfmt stuff." comment :)

Oh, they were not talking about the implementation of these things. Just the the user side:

printf("Error: File `%s` in batch %d failed.", file.c_str(), batch) vs fmt::print("Error: File `{}` in batch {} failed.", file, batch)

One of which is objectively safer and more portable than the other. They didn't care. "I like what I've been doing for the last 20 years already better because it looks better.". "No Its not because I'm just used to it." "If you are careful it is just as safe. But you gotta know what you are doing."

And best of all - classic elitism:

"If you are not smart enough to do it right with printf, maybe you shouldn't be a C++ programmer. Go write C# or something instead."

The same person was not smart enough to do it right in many places as I've proven with a static analyzer.

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

#232

Post by vanderZwan »

dadrian wrote: post #172
tptacek wrote: post #157

Earlier quoted context omitted.

I actively dislike Zig's memory safety story, but this isn't a real argument until you can start showing real vulnerabilities --- not models --- that exploit the gap in rigor between the two languages. Both Zig and Rust are a step function in safety past C; it is not a given that Rust is that from Zig, or that that next step matters in practice the way the one from C does.

I like Zig, although the Bun Github tracker is full of segfaults in Zig that are presumably quite exploitable. Unclear what to draw from this, though. [1]: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

Wasn't Bun the project where the creator once tweeted something along the lines of "if you're not willing to work 50+ hours a week don't bother applying to my team"? Because if so then I'm not surprised and also don't think Zig is really to blame for that.

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

#233

Post by Klonoar »

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…

Rust isn’t a babysitter so much as it is having a second adult in the room that you’re bouncing stuff off of; they just care about memory safety and will tell you when you’re doing something stupid. You can override them if you want to.

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

#234

Post by bryanlarsen »

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…

Or more likely, sprinkle .clone() liberally and Arc or an Arc wrapper (ArcSwap, tokio's watch channels, etc) strategically.

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

#235

Post by K0nserv »

dayvster wrote: post #229
K0nserv wrote: post #174

I mostly don't agree with this take. A couple of my quibbles: "Cognitive overhead: You’re constantly thinking about lifetimes, ownership, and borrow scopes, even for simple tasks. A small CLI like my notes tool suddenly feels like juggling hot potatoes." None of this goes away if you are using C or Zig, you just get less help from the compiler. "Developers are not idiots" Even intelligent people will make mistakes be…

this is an excellent example do you mind if I examine it a bit closer and perhaps use it in my article?

Yes of course, although, as I said in a sibling comment, it's a bit convoluted as an example. The fundamental problem is that the xor mutable and shared reference rule gets in your way when you access separate fields through &self and &mut self even if the borrows are non-overlapping.

There has been discussion to solve this particular problem[0].

0: https://github.com/rust-lang/rfcs/issues/1215

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

#236

Post by rixed »

quotemstr wrote: post #218
SkiFire13 wrote: post #194

Earlier quoted context omitted.

The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one.

> The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one. That's a myth that just won't die. How is it that people simultaneously believe 1) GC makes a language slow, and 2) Go is fast? Go's also isn't the only safe GC. There are plenty of good options out there. You are unlikely to encounter a performance issue using one of these languages that you could resolve only wit…

> How is it that people simultaneously believe > 1) GC makes a language slow, and > 2) Go is fast?

Easy one: either not the same people, or people holding self contradicting thoughts.

GC are slow not only because of scanning the memory but also because of the boxing. In my experience, 2 to 3 times slower.

Still a better tradeoff in the vast majority of cases over manual memory management. A GC is well worth the peace of mind.

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

#237

Post by cheshire_cat »

quotemstr wrote: post #218
SkiFire13 wrote: post #194

Earlier quoted context omitted.

The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one.

> The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one. That's a myth that just won't die. How is it that people simultaneously believe 1) GC makes a language slow, and 2) Go is fast? Go's also isn't the only safe GC. There are plenty of good options out there. You are unlikely to encounter a performance issue using one of these languages that you could resolve only wit…

Go is fast compared to Python or Ruby. Go is not fast compared to C.

I think people that talk about GC'd languages being slow are usually not building Rails or Django apps in their day to day.

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

#238

Post by erk__ »

articulatepang wrote: post #133

> Last weekend I’ve made a simple CLI tool for myself to help me manage my notes it parses ~/.notes into a list of notes, then builds a tag index mapping strings to references into that list. Straightforward, right? Not in Rust. The borrow checker blocks you the moment you try to add a new note while also holding references to the existing ones. Mutability and borrowing collide, lifetimes show up, and suddenly you’re…

Pointers to a vec could also be invalidated at any point when adding a new element and causing a reallocation

(I think Miri will shout at you if you use a invalidated pointer here)

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

#239

Post by Klonoar »

iphone_elegance wrote: post #60

when I think of rust I think of beauties like this, self.last.as_ref().unwrap().borrow().next.as_ref().unwrap().clone() I know it can be improved but that's what I think of

Without any context it’s impossible to tell if code needs to be that obtuse or if uou somehow built your way into a setup that you could’ve avoided. ;P

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

#240

Post by nmilo »

shmolyneaux wrote: post #210
nmilo wrote: post #170

I don't know why anyone would write CLI tools in rust or zig. I/O is going to be your bottleneck way more often than GC, in fact I don't really get the GC hate outside of game dev, databases and other memory intensive applications. Why not use Go, Python, etc? People try to make a false dichotomy between memory safety vs. non-memory safety when really it's GC vs. no GC --- memory safety without it is going to be hard…

Instant startup times are really nice. You definitely notice the difference. It also means that you can be a bit lazier when creating wrappers around those tools (running 1000's of times isn't a problem when the startup is 1ms, but would be a problem with 40ms of startup time). Distribution can also be a lot easier if you don't need to care about the user having a specific version of Python or specific packages avail…

Fair. Python was probably a bad example. I think we need more languages like Go because even with its downsides, for projects that don’t need explicit memory control I’m picking it over rust and zig every time
Post reply on HN