Comment by qalmakka | Hacker News Reader

Comment by qalmakka | Hacker News Reader

Parent Full thread

I don't know. I know that the old interface was less pleasant than it could be, but breaking every single program ever written in Zig to change it for a super unwieldy API felt to me more like the authors being unnecessarily fastidious than striving for "no hidden control flow". Every single language has a shitty API or two - it's impossible to have none, and to be fair the new one is way too clunky anyway.

Like, what does "avoiding hidden control flow" even mean? What value there is in having no convenient facility to do buffered I/O? Hidden buffered output wasn't really a problem even 40 years ago, it's one of those things everybody needs and those who don't are well aware of how to use the primitives and do it properly.

But let's be clear, I have nothing against Zig, I quite like it from a language nerd standpoint and I think it's very neat - I just don't understand what is the intended target to be honest. If I'm not looking for a safe language, C is fine, and for all its warts and bullshit C++ works with basically everything under the sun. If I want safety, there is Rust which basically already enforces the same patterns you need to follow to get safe C/C++ programs anyway - in my experience, 99% of the time someone whines that the borrow checker is stopping them from doing something, it's because they are making a massive logic mistake and they didn't notice there's some hidden unsoundness (like pointers with unclear lifetimes, etc).

We have a few large Zig projects at $WORK, and the value prop for us was something like:

1. We need good C ABI compatibility to integrate with the Python ML ecosystem.

2. It's by far the easiest language I've used to write correct, high-performance kernels. We have, among other things, the world's fastest protobuf parser [0] and a variety of tailor-made concurrent data structures and math-heavy logic.

3. Sure, C works, but just having defer, errdefer, proper errors, exhaustive switches, comptime, and other modern language niceties makes the process much, much easier. It's night and day better (personal opinion), and I'll need a strong reason to go back.

4. It's a simple language. That doesn't always matter, but given current broader organizational dynamics it was a lot easier sell than Rust or C++.

5. For the domain, we were going to have to write nearly everything from scratch anyway, so the limited library support compared to a newer language wasn't a notable negative.

And so on. Basically, it's easy to use, has perf/correctness tradeoffs suiting us nicely, and for other reasons the downsides weren't especially applicable (e.g., these major breaking changes basically just eat a dev day per year, and we get to pick and choose to land them on a slow week for even less dev impact).

I think another language could have worked fine. I've coded professionally in all the usual culprits and could have made them work. I think we would've been in a worse place had we done so, but not that much worse.

[0] Long story, we're forced to use protos to integrate with some other companies, and the schema sucks. Gzipped json would be better than some of the choices they made. Parse speed is obviously data-dependent, but we have a good set of perf tradeoffs for the monstrosity we've been given. Other schemas would behave reasonably well but maybe favour the Go parser or something. We care about deeply nested schemas with tiny, variable-length atomic pieces.

These are technical questions with very good technical answers. Consider doing research rather than taking potshots at the design.

In particular, Zig is still pre-1.0 and is very explicitly subject to change, and it was very important to make this change before reaching 1.0

Reply on news.ycombinator.com