Zig is pretty neat. Compiles quickly, integrates nicely with C and its sdtlib was designed with explicit allocators in mind. It's a perfectly fine choice for building small CLIs, but many of the criticisms of rust just don't land right of me. Let's go through some slightly exaggerated interpretations of them. 1. Relying on the compiler for memory management makes you a bad programmer: Every skill has its applications, but having a compiler that ensures memory safely (for the most part) changes what is required of a good programmer and being able to safely manage memory by hand is less important. 2. The borrow checker is all or nothing: If you use unsafe or turn your memory bugs into logic bugs by using indexes you do miss out on safety guarantees of the borrow checker, but a) Rust has other compelling features, e.g. pattern matching, parametricity, b) Zig/C safety doesn't hold up better when doing things that require unsafe in Rust, c) the unsafe use and index wrangling can be encapsulated. The rest of your code can use the borrow checker just fine. 3. But safety is more than memory safety: Of course there is. I think this is a bit of a straw man argument, because I don't think that's a common claim the rust community let alone the foundation makes. 4. Rust strongly encourages you to structure your code around the compiler: I think this claim is valid, but I want to dispute that this is such a bad thing. You are probably a log smarter than the compiler. So you need to dumb it down, so the compiler will understand. Code that requires less brain power to understand is usually good. I've had some experiences where the borrow checker guided me to find a nicer structure for my code. The learning curve however is real. It takes a lot of time to build the intuition around the borrow checker and not run head first into it all the time. IMHO for small CLI tools it's fine to clone your way out of a dead end, even if it seems ugly.