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

171–180 of 412 posts

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

#171

Post by nayuki »

Aurornis wrote: post #110
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…

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

> Arc isn't really garbage collection. It's like a reference counted smart pointer

Reference counting is a valid form of garbage collection. It is arguably the simplest form. https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

The other forms of GC are tracing followed by either sweeping or copying.

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

Unless you have cycles, in which case the objects are not dropped. And then scanning for cyclic objects almost certainly takes place at a non-deterministic time, or never at all (and the memory is just leaked).

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

No. That's like saying "a car is a car; a vehicle is anything other than a car". No, GC encompasses reference counting, and GC can be deterministic or non-deterministic (asynchronous).

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

#172

Post by dadrian »

tptacek wrote: post #157
jasonpeacock wrote: post #108

Earlier quoted context omitted.

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

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

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

#173

Post by seabrookmx »

GardenLetter27 wrote: post #161

Nope, rust-analyzer is incredible whereas the Zig LSP felt worse than Go. I agree the borrow checker can be a pain though, I wish there were something like Rust with a great GC. Go has loads of other bad design decisions (err != nil, etc.) and Cargo is fantastic.

Syntactically speaking, Gleam fits the bill. It's very new/immature though and isn't in the same performance bracket since it runs on the BEAM.

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

#174

Post by K0nserv »

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 because they are tired or distracted. Not being an idiot is recognising your own fallibility and trying to guard against it.

What I will say, that the post fails to touch on, is: The Rust compiler's ability to reason about the subset of programs that are safe is currently not good enough, it too often rejects perfectly good programs. A good example of this it the inability to express that the following is actually fine:

    struct Foo {
        bar: String,
        baz: String,
    }

    impl Foo {
        fn barify(&mut self) -> &mut String { 
            self.bar.push_str("!");
            &mut self.bar
        }
        
        fn bazify(&self) -> &str {
            &self.baz
        }
    }

    fn main() {
        let mut foo = Foo {
            bar: "hello".to_owned(),
            baz: "wordl".to_owned(),
        };
        let s = foo.barify();
        let a = foo.bazify();
        s.push_str("!!");
    }
which leads to awkward constructs like

    fn barify(bar: &mut String) -> &mut String { 
        bar.push_str("!");
        bar
    }

    // in main
    let s = barify(&mut foo.bar);

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

#175

Post by liuliu »

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

- 454 instances of "Rchttps://github.com/search?q=repo%3Aservo%2Fservo+Rc%3C&type=...

- 6 instances of "Rchttps://github.com/search?q=repo%3Arusoto%2Frusoto+Rc%3C&typ...

- 0 instance for "Rchttps://github.com/search?q=repo%3Acgag%2Floc+Rc%3C&type=cod...

(Disclaimer: I don't know what these repos are except Servo).

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

#177

Post by [deleted] »

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.

[deleted]

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

#178

Post by mattwilsonn888 »

rowanG077 wrote: post #152
mattwilsonn888 wrote: post #134

Earlier quoted context omitted.

No. It is not an invisible safeguard - it yaps and significantly increases compile time and (a matter of great debate) development effort. It is a helmet, just accept it. Helmets are useful.

It is a helmet. But at least it's a helmet in situations where you get into brain cracking accidents multiple times a day. In the end the helmet allows you to get back up and continue your journey compared to when you had no helmet.

We're talking about Zig not C. Same argument will apply to Odin.

These modern approaches are not languages that result in constant memory-safety issues like you imply.

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

#179

Post by K0nserv »

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…

Not Python because getting Python to run on different machines is an absolute pain.

Not Go because of its anaemic type system.

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

#180

Post by mattwilsonn888 »

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.

Try and appreciate the humor in what you're replying to without fully discounting the point of it.
Post reply on HN