Sounds like Andrew is using the same argument as Bjarne Stroustrup: if you use it right, you don't write bugs. It hasn't really worked out for C++.

▲

nickmonad 3 days ago | parent [-]

He's not.

> "There's a dichotomy being presented here where you have to either choose a "style guide" or a programming language feature in order to avoid bugs. The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it. You're not giving TigerBeetle nearly enough credit. Quite simply they put in the time to find and eliminate the bugs, they make an effort to maintain a healthy relationship with ZSF, and Bun did not do that."

The reference to TigerBeetle is important, and a bit under-explained for the point he's trying to make. They have consistently attributed things like design and deterministic simulation testing to their success and reliability, which has nothing to do with Zig as a language. Some things might be _easier_ in Zig, such as static memory allocation, but ultimately, a holistic approach brings success, not one individual tool used "right".

▲

nicce 3 days ago | parent [-]

But is TigerBeetle then even reasonable reference as an argument for Zig? Maybe they could have reached the same with plain C.

	▲	nickmonad 3 days ago \| parent [-]
		Zig still offers a lot of great additions that make systems work more reliable. Optionals and comptime are two helpful things C does not have, and there are plenty others. One of their core devs addressed this in a thread over on Lobsters [1] > Bounds checks, checked arithmetic, strongly-typed alignment, strongly-typed error codes, tagged unions, explicit undefined are some rather important language features. If Zig didn't exist, TigerBeetle would probably have been written in C, and the safety gap between C and Zig is just gigantic. And safety is one aspect of the language, Zig has a lot of going on for it elsewhere! [1] https://lobste.rs/s/6rkdik/rewriting_bun_rust#c_8gebpa