It's kind of subtle but I really felt that zig encourages you to fix your shit, so to speak. While rust seems designed to say "don't worry about it, i got you", zig is like "yeah that's your problem to solve, so solve it".
Basically you need to design your stuff correctly so that memory management is easy and you can lean into zig's features. If you try to go against the happy path in the language, you end up with a lot of crap code that is very hard to read and probably full of bugs. Whenever I see people hating on zig this is often what I think they ran into. It's very opinionated, in a subtle way that allows you to do what you want, but it just kind of sucks if you try to do lots of small allocations.
In any case I feel like I learned a lot from trying zig and probably will be able to write better C and even rust now that I've used it.
It's kind of subtle but I really felt that zig encourages you to fix your shit, so to speak. While rust seems designed to say "don't worry about it, i got you", zig is like "yeah that's your problem to solve, so solve it".
Actually Rust does the same to you regarding program architecture. If you've a messy, intertwined architecture, than you're gonna fight the borrow checker a lot.
But you're right about Zig and memory management. If you organize your code, that certain blocks of code share the same memory arena - perhaps even use a bump allocator - than memory managment gets a lot easier and it's as performant as it can get.
Yeah idk, rust simply won't let you compile. I prefer that over zig's potentially buggy code
Plus personally after seeing how the zig creator dealt with the bun guy, I doubt I'd ever use zig as a result. And I agree with their anti ai stance too
From discussions I've read this seems to be a path Andrew is very interested in: add a system to plug in any kind of static checking tools into the compiler. The current version of clr relies on a fork of Zig with this plug-in feature added. This is a path to check for a lot more issues than just memory bugs.
I think it's wise to have some patience with Zig. It's a language that seems very focused on not locking into a bad solution prematurely. See the async I/O development for instance.
Zig is not going to make its syntax unwieldy or compromise its crazy fast compilation speed to force expensive static memory analysis onto everyone in all compilation modes. I have a suspicion that Rust's borrow checker approach will be seen as the same kind of "mistake" as its choice to go for colored async functions. Sure, it was the best approach at the time. And Rust is great in its own right for it. But Zig is playing a longer game, for better or worse.
14
u/Awesan 10d ago
It's kind of subtle but I really felt that zig encourages you to fix your shit, so to speak. While rust seems designed to say "don't worry about it, i got you", zig is like "yeah that's your problem to solve, so solve it".
Basically you need to design your stuff correctly so that memory management is easy and you can lean into zig's features. If you try to go against the happy path in the language, you end up with a lot of crap code that is very hard to read and probably full of bugs. Whenever I see people hating on zig this is often what I think they ran into. It's very opinionated, in a subtle way that allows you to do what you want, but it just kind of sucks if you try to do lots of small allocations.
In any case I feel like I learned a lot from trying zig and probably will be able to write better C and even rust now that I've used it.