so its self-hosted for x86_64 only so far, which is fine if communicated
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
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.
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.
If your point is that Rust was more stable (and why not, even an overall better project) at the same age, then I'm happy to immediately concede the point. But that doesn't really have any influence on the main question, does it?
Zig is in a weird spot because it has a similar momentum behind it than some other languages I was exited about, it has even more hype (and is very hype driven with streams and everything) yet it has from my experience with it much more stability issues. And I assume some of this comes from a relay complex compile time system that is harder to implement rigorously than some other things.
I also have to say that I find these responses unnecessarily combative.
Yes, and I still stand by my assertion. Next to you in the "early adopter spectrum" are people who can put up with more breakage on one side, and people who cannot put up with the current level on the other side. At any point in time the project will be somewhere along that spectrum and some people will be on one side of that line and others will be on the other.
Similarly, different things going on in the project will move the line in either direction. Switching to a new compiler implementation is unsurprisingly a source of bugs, if you want to use Zig now, you will have to accept the current state of things.
> it has even more hype (and is very hype driven with streams and everything)
Hype driven... you mean Andrew's 100 people streams? Or my 30 people streams? What hype-driving streams are you referring to. My YouTube channel with 4k subs (hit that milestone today btw)?
> I also have to say that I find these responses unnecessarily combative.
I really don't know what to tell you. If Zig is too broken for your liking, don't use it. If other projects at the same level of age/popularity/whatever had a level of breakage that you found tolerable, then great, and if Zig doesn't meet that standard, then it means, by definition, that it's too early for you to use it.
If you want to make a different point, then state it clearly, from the early adoption perspective, I don't see any argument to be discussed here.
More like release notes with 1,000 upvotes on Reddit:
https://www.reddit.com/r/programming/comments/rl87pr/zig_pro...
> The self-hosted compiler brings many advantages, but it did cost us a significant amount of effort and time. While Zig is still going up in popularity and starting to make a tiny dent in the industry, people that have been following along for long enough will know that this work has reduced our momentum in the last two years.
> Bug fixes in the compiler have been often put on hold since fixing the bootstrap compiler was ultimately useless, and accepted feature proposals have been piling up because it would have required implementing everything twice.
Pretty much all of the talks and blog posts on the `in-Zig` compiler are about better performance, lower memory footprint, e.t.c.
I would much rather have heard a talk about how they improved correctness through automatic testing, formal methods, simple language design e.t.c.
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.
But - it's plastered all over the entire project that it is a work in progress. This post itself is talking about how for loops are getting broken. It's an ambitious project with a talented and ambitious team, and their vision and execution so far has been awesome. I'm not using Zig for anything resembling production code at the moment - because it's going to break. But when it stabilizes - there is a lot of potential.
Isn’t that the point of nightly
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.
Thanks in advance.
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.
Using phrases like "fundamental culture problem" or "at least some stability"
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.
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.
But you knew this already and are once again telling lies on the internet to defraud developers of their time. It's no wonder zig bugs go years without fixes since you spend all your time patrolling the internet for negative mentions of zig.
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?
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.
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)
I'd give everything for a zig compiler that's 10 times as slow but actually compiles my code.
Also testing infrastructure. Zig really needs fuzzing and property testing tooling build-in. Hitting stage 2 with arbitrary autogenerated zig code and IR, would have really helped detect regressions for example.