It's hard to imagine Zig ever becoming stable and conservative. Even at 10 years old, it's still as beta as ever. At some point the churn becomes part of the culture.

Not a complaint, just an observation. I like that they are trying new things.

I wouldn't be so sure about that. I do think there's a bit of scope creep, especially with the LLVM replacement stuff, but I don't think it's bad enough for the language to never come out. Most notable languages have at least one large corporate sponsor behind them, Zig doesn't.

I’m a casual user and the 0.16 changes scare me. I tried multiple attempts now, even with full LLM support to upgrade and the result is just a) painful and b) not very good. I have high doubts that the current IO system of 0.16 will make it for another release given the consequences of their choices.

Here's some advice:

1. if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work (because they're still tinkering with them) also you can't expect docs until the design is somewhat finalized (which is not yet, fyi)

2. llms don't help when trying to make sense of the above (a feature that is not complete, that has no docs other than some hints in commit messages, that changes every other commit), reserve llms for when things are stable and well documented, otherwise they will just confuse you further.

If you want to try new features before they land in a tagged release, you must engage with the development process at the very least.

> if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work

Is the completeness of each API formally documented anywhere? Maybe I missed something but it doesn't seem like it is, in which case the only way to know would be to follow what's happening behind the scenes.

Zig cuts releases. This API is not on a release of Zig yet. It's only available through nightly builds of master. "Casual users" should stick to releases if they don't want to deal with incomplete APIs.

That's not really the issue. The stable API is incompatible with the API that will launch with 0.16. It's not really relevant if I'm playing with incompletely API, I want to know how I can migrate to it. I did not move yet to 0.16, but I wanted to see.

The migration pain will be the same once it launches unless they revert back, which does not seem likely at all.

But the point is: potentially every API is unstable.

> if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work

From what I can tell pretty much everything can be broken at any point in time. So really the only actual advise here is not to use the language at all which is not reasonable.

> llms don't help when trying to make sense of the above

That has not been my experience. LLMs were what enabled me to upgrade to 0.16 experimentally at all.

> If you want to try new features before they land in a tagged release, you must engage with the development process at the very least.

No, that is unnecessary gatekeeping. 0.16 will become stable at one point and I don't want to wait until then to figure out what will happen. That's not how I used Rust when it was early (I always also tried nightlies) and that line of thinking just generally does not make any sense to me.

The reality is that Zig has very little desire to stabilize at the moment.

The flipside of that is that the incomplete API should be in a separate branch until it is ready to be included in a release, so that people can opt in instead of having to keep in mind what parts of the API they aren't supposed to be using. It doesn't seem like you expect the changes to be finalised in time for 0.16.

[deleted]