Comment by karmakaze | Hacker News Reader

Comment by karmakaze | Hacker News Reader

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’t teach you good patterns, and it won’t save you from bad design choices.

In the short times that I wrote Rust, it never occurred to me that my lifetime annotations were incorrect. They felt like a bit of a chore but I thought said what I meant. I'm sure there's a lot of getting used to using it--like static types--and becomes second nature at some point. Regardless, code that doesn't use unsafe can't have two threads concurrently writing the same memory.

The full title is "Why Zig Feels More Practical Than Rust for Real-World CLI Tools". I don't see why CLI tools are special in any respect. The article does make some good points, but it doesn't invalidate the strength of Rust in preventing CVEs IMO. Rust or Zig may feel certain ways to use for certain people, time and data will tell.

Personally, there isn't much I do that needs the full speed of C/C++, Zig, Rust so there's plenty of GC languages. And when I do contribute to other projects, I don't get to choose the language and would be happy to use Rust, Zig, or C/C++.

> 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 back in the day. But the reality is that most codebases don't need to be clever and they do need a babysitter.

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 wondering why - other than proselytizing Zig - this article would make such a direct and narrow comparison between only Zig and Rust.

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.

OCaml for example,

Unix system programming in OCaml, from 1991

https://ocaml.github.io/ocamlunix/

It’s such a nice language, too. It’s too bad it doesn’t get more attention. I know someone who regularly runs a couple of utilities written in Haskell, but they’re the only Haskell code in his entire organization. It’s a shop that has C, C++, Rust, JavaScript, TypeScript, Python, and Go in production, Java in legacy production, and has half a dozen other languages in production support situations. Haskell has not caught on there, though.

I’m aware a few companies use primarily OCaml just as a few use primarily some form of Lisp. It’s just that some of these really nice languages don’t see as much use as they could.

I think this focus cuts both ways though - most "one & done" CLI tools will not be bottlenecked by a GC. Many are so performance insensitive that Python is totally fine, and for most of the rest the performance envelope of Go is more than enough. Why would I reach for Rust or Zig for these? "I like C, Zig is like C" is a totally acceptable reason, but then this whole article is preaching to the choir.

I was with you on using safe languages Go/Python. I disagree that using Zig == using Rust. Many CLI programs get run as root (sudo or otherwise) either necessarily or out of laziness/convenience.

It isn't even really that -- most CLI tools are single-threaded and have a short lifespan, so your memory allocation strategy can be as simple as allocating what you need as you go along and then letting program termination clean it up.

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.

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

Reply on news.ycombinator.com