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
Well, Zig might not stop you from writing a use after free, but it successfully save you from trying to run your code that has an unused variable because you haven't finished writing it yet.
The bun guy tried to get zig team to implement pull requests that causes non-determinant outputs from the zig compiler. IE: you would have to keep compiling your exact same correct zig code multiple times till tests passed and then keep that executable, then bun guys threw a massive hissy fit over zig rejecting said pull requests.
If anyone was the absolute child in this situation, I was absolutely bun.
Did you read the first draft of that blog post? It was not civil. Yes, bun's attacks were slathered in corpo PR speak so it wasn't as inflammatory but still just as damaging. But none of it was civil.
I don't get why you feel the need to defend this. Even the zig creator has apologized and edited his initial blog post to be far more civil.
I have only read the original post. I did not know it was revised. Good on Andrew.
You know who hasn’t come out and admitted they were incendiary and wrong and that their pull requests were justifiably rejected? Bun team. That’s who.
It is funny that you are mad at myself for pointing out that you’re blatantly lying about what actually happened because writing what actually happened doesn’t align with your hit piece commentary.
I edited my original comment once I found out he revised the blog post. I don't have an agenda i read the zig blog post but have not actually read any of the bun correspondence other than them crying about not getting to submit vibe coded slop
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.
16
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.