4 ms·

I'm not so familiar with Zig, are you saying that the compiler fails to compile correct (i.e. according to spec) code?

by dist1ll 4y ago

j-pb 4y ago
Yeah, theres a surprising amount of stuff that's buggy, think `if` or `recursive structs with pointers` level stuff.
- mattgreenrocks 4y ago
  Can you substantiate this further? I don't see how basic stuff like that could be subtly buggy, the Zig devs are very qualified IMO.
  - mirashii 4y ago
    Here's a pretty substantial bug from just a week ago: https://github.com/ziglang/zig/issues/13211 https://github.com/ziglang/zig/issues/13211
    - singularity2001 4y ago
      "stage1 is expected to be broken in many ways and does not handle non-x86_64 C ABI at all." so its self-hosted for x86_64 only so far, which is fine if communicated
      - somethingor 4y ago
        stage1 is the non-self-hosted compiler (the one written in C++)
  - kristoff_it 4y ago
    We do have a good number of known miscompilations, I can substantiate for the parent poster with a simple link: https://github.com/ziglang/zig/labels/miscompilation https://github.com/ziglang/zig/labels/miscompilation It's also true that the self-hosted compiler has caused new bugs to pop up, which in turn made us write new behavior tests. To me that's to be expected with every project aimed at rewriting an existing system. It's also true that proper testing infrastructure is critical, and we do have it, although the requirement of more than 8gb of ram has not played in our favor in the past. We plan to revamp our CI systems once we are done with this release. That said, it's a v0 language. If you choose to use it, you know you're coming with us on a ride. The choice of how much to prioritize correctness vs progress is influenced by many things that are going on in the project and there is no one clear strategy that trumps all others. Quoting j-pb from another comment: > A language that (does or doesn't) compile your code in 0.1 seconds to a broken binary is worse than piping your code into dev/null. Eh, yes, but also no. Obviously a compiler needs to work correctly to be useful, but our priority right now is to move the project forward using our best judgment, not ensure that it has maximal utility to early adopters. I do agree with the sentiment that the compiler needs to be reliable, it's just that Zig is v0 for a reason. In concrete terms I think that once we're done with an initial adjustment phase, you will find that the compiler will have a steady increase in stability over time. That's how it was with the bootstrap compiler before we started the self-hosted work. Also, quoting dist1 from up the comment tree: > I'm not so familiar with Zig, are you saying that the compiler fails to compile correct (i.e. according to spec) code? Keeping in mind everything that I just wrote, note that Zig doesn't have a spec yet. Sometimes, some issues in the compiler are the result of discovering that a design choice needs to be amended. Recent example of that: https://github.com/ziglang/zig/issues/12251 https://github.com/ziglang/zig/issues/12251
    - the_mitsuhiko 4y ago
      > Eh, yes, but also no. Obviously a compiler needs to work correctly to be useful, but our priority right now is to move the project forward using our best judgment, not ensure that it has maximal utility to early adopters. I feel like I’m a potential early adopter and the amount of miscompilation I ran into playing around with it really made me lose interest. It seems like the priorities are set somewhere else entirely.
      - kristoff_it 4y ago
        Going by your own comment, you seem to not be an "early enough" adopter. That's totally fair, maybe Zig will be more interesting for you once it stabilizes more in the future.
        the_mitsuhiko 4y ago
        I don’t believe this to be true. Zig is 6 years old now going by Wikipedia. In comparison I use Rust in an more extensive way than Zig for almost 20 years now. I for sure wrote more Rust in 2012 when it was ~2 years? old than Zig last year, yet I don’t remember miscompilations on that level. The same is true for my recollection of using very early D which however at this point was in an earlier life of mine and very fuzzy.
        pjmlp 4y ago
        2022 - 2010 ==> 12 years. :)
        ksec 4y ago
        20 years? Something doesn't add up.
        the_mitsuhiko 4y ago
        It’s a typo. Was supposed to say 10.
        4y ago
anonymoushn 4y ago
We're using the C++ compiler rather than the self-hosted compiler because the self-hosted compiler does not yet support async. Yes, it sometimes fails to compile correct code (by crashing) or compiles correct code to incorrect code.
- puffoflogic 4y ago
  - 8n4vidtmkvmk 4y ago
    i hope not. i like the idea of zig but bad stewards can ruin an otherwise good project

I'm not so familiar with Zig, are you saying that the compiler fails to compile correct (i.e. according to spec) code?

j-pb 4y ago

Yeah, theres a surprising amount of stuff that's buggy, think `if` or `recursive structs with pointers` level stuff.

mattgreenrocks 4y ago
Can you substantiate this further? I don't see how basic stuff like that could be subtly buggy, the Zig devs are very qualified IMO.
- mirashii 4y ago
  Here's a pretty substantial bug from just a week ago: https://github.com/ziglang/zig/issues/13211 https://github.com/ziglang/zig/issues/13211
  - singularity2001 4y ago
    "stage1 is expected to be broken in many ways and does not handle non-x86_64 C ABI at all." so its self-hosted for x86_64 only so far, which is fine if communicated
    - somethingor 4y ago
      stage1 is the non-self-hosted compiler (the one written in C++)
- kristoff_it 4y ago
  We do have a good number of known miscompilations, I can substantiate for the parent poster with a simple link: https://github.com/ziglang/zig/labels/miscompilation https://github.com/ziglang/zig/labels/miscompilation It's also true that the self-hosted compiler has caused new bugs to pop up, which in turn made us write new behavior tests. To me that's to be expected with every project aimed at rewriting an existing system. It's also true that proper testing infrastructure is critical, and we do have it, although the requirement of more than 8gb of ram has not played in our favor in the past. We plan to revamp our CI systems once we are done with this release. That said, it's a v0 language. If you choose to use it, you know you're coming with us on a ride. The choice of how much to prioritize correctness vs progress is influenced by many things that are going on in the project and there is no one clear strategy that trumps all others. Quoting j-pb from another comment: > A language that (does or doesn't) compile your code in 0.1 seconds to a broken binary is worse than piping your code into dev/null. Eh, yes, but also no. Obviously a compiler needs to work correctly to be useful, but our priority right now is to move the project forward using our best judgment, not ensure that it has maximal utility to early adopters. I do agree with the sentiment that the compiler needs to be reliable, it's just that Zig is v0 for a reason. In concrete terms I think that once we're done with an initial adjustment phase, you will find that the compiler will have a steady increase in stability over time. That's how it was with the bootstrap compiler before we started the self-hosted work. Also, quoting dist1 from up the comment tree: > I'm not so familiar with Zig, are you saying that the compiler fails to compile correct (i.e. according to spec) code? Keeping in mind everything that I just wrote, note that Zig doesn't have a spec yet. Sometimes, some issues in the compiler are the result of discovering that a design choice needs to be amended. Recent example of that: https://github.com/ziglang/zig/issues/12251 https://github.com/ziglang/zig/issues/12251
  - the_mitsuhiko 4y ago
    > Eh, yes, but also no. Obviously a compiler needs to work correctly to be useful, but our priority right now is to move the project forward using our best judgment, not ensure that it has maximal utility to early adopters. I feel like I’m a potential early adopter and the amount of miscompilation I ran into playing around with it really made me lose interest. It seems like the priorities are set somewhere else entirely.
    - kristoff_it 4y ago
      Going by your own comment, you seem to not be an "early enough" adopter. That's totally fair, maybe Zig will be more interesting for you once it stabilizes more in the future.
      - the_mitsuhiko 4y ago
        I don’t believe this to be true. Zig is 6 years old now going by Wikipedia. In comparison I use Rust in an more extensive way than Zig for almost 20 years now. I for sure wrote more Rust in 2012 when it was ~2 years? old than Zig last year, yet I don’t remember miscompilations on that level. The same is true for my recollection of using very early D which however at this point was in an earlier life of mine and very fuzzy.
        pjmlp 4y ago
        2022 - 2010 ==> 12 years. :)
        ksec 4y ago
        20 years? Something doesn't add up.
        the_mitsuhiko 4y ago
        It’s a typo. Was supposed to say 10.
        4y ago

anonymoushn 4y ago

We're using the C++ compiler rather than the self-hosted compiler because the self-hosted compiler does not yet support async. Yes, it sometimes fails to compile correct code (by crashing) or compiles correct code to incorrect code.

puffoflogic 4y ago
- 8n4vidtmkvmk 4y ago
  i hope not. i like the idea of zig but bad stewards can ruin an otherwise good project