I mean, zig is a better C, not a better C++. Rust tries to be a better C++. I really like C, and I like zig. I don’t like C++ and I don’t like Rust.

That being said, I do agree, zig changes a lot, and if you’re doing LLM generated code, yes, that sucks.

However:

With coding agents allowing 100x more code to be written, this also means you need to scrutinize 100x more Zig code for memory issues. Without formal verification, the surface area of the search space to enumerate to find bugs is just so much larger now.

get good? Even Bjarne Stroustrup says this.

The issue is you should be being careful about how you allocate. You should be doing that as little as possible. You should be using the standard library collections which are well tested. Some stuff is just plain ugly, like when you need to do some string manipulation and now you have to decide where you want to allocate. But largely… it’s not so bad if you are actually considering your API and deciding what are call site concerns and what are API concerns.

Seriously, back to Stroustrup, who has written far more and better code than me:

Think about resources in general, rather than simply about memory.

If systematic application of these techniques is not possible in your environment (you have to use code from elsewhere, part of your program was written by Neanderthals, etc.), be sure to use a memory leak detector as part of your standard development procedure, or plug in a garbage collector.

The problem is you’re throwing this into LLMs, which are trained on codebases that do not make their opinions or assumptions explicit, are largely crap (see Sturgeons Law), and are largely from other programming languages. Of course it sucks at zig. That’s not zig’z fault. That’s your LLM sucking ass.

If you give up your LLM or use it sparingly, you get a vastly different experience. And if you use your LLM in a codebase that’s already good, it will pick up your good conventions and continue them.