4 ms·

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"

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 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.

kuramitropolis 4y ago
Does/will Zig support the Actually Portable Executable format? https://justine.lol/ape.html https://justine.lol/ape.html
- sobeston 4y ago
  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.
- DrNosferatu 4y ago
  This. Also have this very same question / use “Cosmopolitan” LibC with Zig. - Zig Team? Thanks in advance.
pmarreck 4y ago
> 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)
- kristoff_it 4y ago
  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 https://github.com/ziglang/zig/tree/master/test
  - pmarreck 4y ago
    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
j-pb 4y ago
The bug that's currently blocking me from any work using master is https://github.com/ziglang/zig/issues/12325 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.
- nicoburns 4y ago
  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.
  - rofrol 4y ago
    he just want to force zig devs to tackle his problems first. Using phrases like "fundamental culture problem" or "at least some stability"
    - j-pb 4y ago
      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.

kuramitropolis 4y ago

Does/will Zig support the Actually Portable Executable format? https://justine.lol/ape.html https://justine.lol/ape.html

sobeston 4y ago
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.
DrNosferatu 4y ago
This. Also have this very same question / use “Cosmopolitan” LibC with Zig. - Zig Team? Thanks in advance.

pmarreck 4y ago

> 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)

kristoff_it 4y ago
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 https://github.com/ziglang/zig/tree/master/test
- pmarreck 4y ago
  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

j-pb 4y ago

The bug that's currently blocking me from any work using master is https://github.com/ziglang/zig/issues/12325 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.

nicoburns 4y ago
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.
- rofrol 4y ago
  he just want to force zig devs to tackle his problems first. Using phrases like "fundamental culture problem" or "at least some stability"
  - j-pb 4y ago
    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.