Live data from Hacker News

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

dayvster.com

181–190 of 412 posts

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

#181

Earlier quoted context omitted.

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

As Rust Zig has type-safe enums/sum types. That alone eliminates a lot of problems with C. Plus sane error handling with good defaults that are better than Rust also contributes to code with less bugs.

Surely there is no borrow checker, but a lot of memory-safety issues with C and C++ comes from lack of good containers with sane interfaces (std::* in C++ is just bad from memory safety point of view).

If C++ gained the proper sum types, error handling and templates in Zig style 15 years ago and not the insanity that is in modern C++ Rust may not exist or be much more niche at this point.

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

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

Go is a great option for CLI tools (even though I'm not a fan of the language itself). Python CLI apps can be a big pain to distribute if you have a bunch of dependencies. I think this is also why Rust and Zig are also attractive.. like with Go it's easy to create a statically compiled binary you can just cp into /usr/local/bin.

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

#183

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

This is awkward. I've written a fair amount of rust. I reach for Arc frequently. I see the memory layout implications now. Do you tend to use a lot of Arenas?

I've not explored every program domain, but in general I see two kinds of program memory access patterns.

The first is a fairly generic input -> transform -> output. This is your generic request handler for instance. You receive a payload, run some transform on that (and maybe a DB request) and then produce a response.

In this model, Arc is very fitting for some shared (im)mutable state. Like DB connections, configuration and so on.

The second pattern is something like: state + input -> transform -> new state. Eg. you're mutating your app state based on some input. This fits stuff like games, but also retained UIs, programming language interpreters and so on on.

Using ARCs here muddles the ownership. The gamedev ecosystem has found a way to manage this by employing ECS, and while it can be overkill, the base DOD principles can still be very helpful.

Treat your data as what it is; data. Use indices/keys instead of pointers to represent relations. Keep it simple.

Arenas can definitely be a part of that solution.

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

#184

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…

[deleted]

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

#185
post #90
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=...

Servo has to interact a lot with a JS runtime, and it needs to be done in a thread safe and concurrent manner.

Plus the html processing needs to be Arc as well, so that tracks.

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

#186

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…

Looking at your code I have more confidence that quoted statement is false.

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

#187

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…

Arguing that one language is more ergonomic but can produce the same safety if you use it unergonomically is... not very useful in a context where safety is highly valued.

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

#188

Earlier quoted context omitted.

> Rust is your lane assist. It relieves you from the burden of constant vigilance. Interesting analogy. I love lane assist. When I love it. And hate it when it gets in the way. It can actively jerk the car in weird and surprising ways when presented with things it doesn’t cope well with. So I manage when it’s active very proactively. Rust of course has unsafe… but… to keep the analogy, that would be like driving in a…

I have also mostly only dabbled with Rust, and I've come to the conclusion that it is a fantastic language for a lot of things but it is very unforgiving. The optimal way to write Python is to have your code properly structured, but you can just puke a bunch of syntax into a .py file and it'll still run. You can experiment with a file that consists entirely of "print('Hello World')" and go from there. Import a json f…

Rust is very forgiving if the goal is not the absolutely best performance. One can rewrite Python code into Rust mostly automatically and the end result is not bad. Recent LLMs can do it without complex prompting.

The only problem is the code would be littered with Rc>. If Rust would have a compact notation for that a lot of pain related to fighting the borrow checker just to avoid the above would be eliminated.

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

#189
post #73

Earlier quoted context omitted.

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.

How did AWS mess up errors?

Maybe I am holding it wrong.

Here is one piece of the problem:

  while let Some(page) = object_stream.next().await {
        match page {
            // ListObjectsV2Output
            Ok(p) => {
                if let Some(contents) = p.contents {
                    all_objects.extend(contents);
                }
            }
            // SdkError
            Err(err) => {
                let raw_response = &err.raw_response();
                let service_error = &err.as_service_error();
                error!("ListObjectsV2Error: {:?} {:?}", &service_error, &raw_response);
                return Err(S3Error::Error(format!("ListObjectsV2Error: {:?}", err)));
            }
        }
    }

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

#190
post #186

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…

Looking at your code I have more confidence that quoted statement is false.

Which statement and why? The code is obviously stupid and convoluted because I threw it together in a minute to illustrate a point.
Post reply on HN