Comment by AndyKelley | Hacker News Reader

Comment by AndyKelley | Hacker News Reader

Parent Full thread

If bugs are your concern, then this upcoming release is good news for you. Total number of open bug reports is 1,124. However if we remove bugs labeled "stage1" - that is - bugs that are no longer applicable because this release changes the default compiler to the self-hosted one - then the number drops to 514. It would be a fair characterization to say that this release cuts the number of known bugs in half. We have those stage1 bug reports still open because I mandated that every one must have test coverage before being closed, even though they are already fixed in master branch.

That said, I would humbly ask for you to trust my leadership on finding the balance on how much effort to spend on bug fixing versus how much to spend on progress. I think you underestimate how much is going to change before Zig tags 1.0. There are still a few experimental and exploratory changes planned, and when software specifications change, bugs are inevitably introduced. Spending the time to iron out 100% of the bugs found from fuzz testing, on a feature that ends up replaced with a different one that also needs to get debugged, is a waste of time, and a disservice to the wider user base of the project. We're better off finding the "sweet spot" for a swift journey, arriving at our destination early, and then busting out the hardcore QA.

I see https://github.com/ziglang/zig/issues/13211 mentioned elsewhere in this thread. I want to point out that getting the C ABI correct when using LLVM is a notoriously perilous process, as any other compiler dev reading HN today can attest, and this regression which lasted for a total of 6 days in master branch without ever gracing a tagged release, is a symptom of the fact that we actually addressed this C ABI problem at its core, added more test coverage, added an abstraction in the LLVM code generation, and fixed the C ABI for several targets.

And finally, I agree that fuzz testing should be integrated into Zig's unit testing system. That would be a nice enhancement.

Does/will Zig support the Actually Portable Executable format?

https://justine.lol/ape.html

This. Also have this very same question / use “Cosmopolitan” LibC with Zig.

- Zig Team?

Thanks in advance.

I believe where this stands is that if someone were to contribute and maintain this, then it could be part of the Zig compiler, however it is not something the Zig team themselves are planning on doing. Maybe give it a shot? I personally find the project interesting and fun but I'm not convinced that it's a good solution.

The bug that's currently blocking me from any work using master is https://github.com/ziglang/zig/issues/12325

That's not really a bug related to unfinished features that might get replaced anyways, but simply one involving recursive structs with pointers between, i.e. linked lists.

Not detecting issues like these feels less like a "these parts are unfinished hence here be dragons" thing and more like a fundamental culture problem.

I'm fine with cutting myself every now and then with a sharp tool and cutting edge technology, but that can also be done while having a ever growing and mature core that promises at least some stability. The only alternative seems to be to pull a Hickey and work on it for two years without releasing anything.

You're using the master branch of a pre-1.0 tool, and you expect it to be stable without regressions? I feel like your expectations are too high.

he just want to force zig devs to tackle his problems first.

Using phrases like "fundamental culture problem" or "at least some stability"

Frankly I don't care if the problem gets fixed or not. I've already started a rewrite in Rust, and I don't plan on revisiting the Zig version until Zig has hit 1.0.

Coming from a Clojure background I generally agree with Hoare's "One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.", and in that sense Zig should easily be more correct than Rust which is much much much more complex.

The fact that that hasn't happened, with Rust being much more production ready for most of it's life, despite some major backwards compatibility breaking changes, leaves two possible answers for me:

1. The Rust developers are magically better programmers, which I believe to be false.

2. The rust community has a general culture for correctness and QA which the Zig community lacks.

I'd be interested in some constructive feedback on your Zig experience. There's nothing I can do with the claim that Zig users have a culture problem, especially since the "the zig community" does not work on the compiler - it's just me and a handful of other people - and I'm not really able to evaluate the claim about Rust being in a more "production ready" state at a comparable point in its life. To be honest, these two points feel like nothing more than personal insults.

So, putting those aside, if you have any actionable experiences to share, such as other problems you ran into, what went well, what went poorly, what workarounds you tried, other experiences you had that could help inform the direction of the project, then these things would help make Zig shine when you revisit 1.0.

Am I missing something here?

You are comparing a language which hit 1.0 and had seven years of additional refinement, to a language which is still at least 2-3 years away from 1.0 and spent most if not all its time in the past 12 months on self hosting compiler?

> Am I missing something here?

Yes. I'm comparing the stability of very early Rust e.g. 0.x, to the stability of Zig now. Not Rust 1.6 with Zig 0.x.

> and then busting out the hardcore QA

This thinking seems... backward (or at least overall counterproductive/like more work) to me. Do you not have a test suite? At least, unit tests for core language features? It seems (with all due respect) a bit irresponsible not to have this, it would at least prevent most regressions in tested code for example (such as breaking "for" loops, as someone else mentioned)

Zig has thousands of tests, but the problem space of a programming language is pretty big, making fuzzing and other similar techniques worth the effort in the long run. The discussion wasn't about the existence of basic unit tests.

https://github.com/ziglang/zig/tree/master/test

I also possibly misinterpreted someone else's comment about "for" breaking, assuming it was a regression instead of an intended syntax change which might have been covered by units. My bad

Reply on news.ycombinator.com