[BonusPlay]

Instead of debating for years (like other languages), zig just tries things out. Worst case you can always rollback changes.

IMO best APIs and designs are those that are battle tested by end users, not won in an argument war during committee meetings.

This makes zig unique. It's fun to use and it stays fresh.

You can always just stay on older version of zig. But if you choose to update to newer version, you get new tools to make your code tidier/faster.

[pjmlp]

Other languages debate for years, because they have a customer base with important applications into production that don't find funny that their code is broken with experiments.

Zig is years away to become industry relevant, if at all, of course they can experiment all they like.

[Pay08]

Obviously, that comes with the language being in beta. If you don't want things broken, use a complete language.

[zarzavat]

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.

[Pay08]

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.

[the_mitsuhiko]

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.

[kristoff_it]

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.

[nickorlow]

I think it benefits the overall ecosystem for them to experiment so other languages can take what works

[quietbritishjim]

> Instead of debating for years (like other languages), zig just tries things out.

Many other languages do try things out, they just do it in a separate official channel from the stable release or unofficial extensions. Depending on how many users the language has, that may still be more implementation experience than Zig making all devs try it.

I suspect the actual difference is the final decision making process rather than the trial process. In C++, language extensions are tried out first (implementation experience is a requirement for standard acceptance) but committee debates drag on for years. Whereas Python also requires trial periods outside the stable language but decisions are made much more quickly (even now that there's a steering rather than single BDFL).

[jiehong]

This is a great point, and it's actually something I really enjoy that the JVM and Java do nowadays by namespacing the new experimental APIs that you test from release to release and then it's stabilized like that, and becomes broadly available.

[SkiFire13]

> IMO best APIs and designs are those that are battle tested by end users

Battle testing an API however requires time and the API to not constantly change.

[Ygg2]

> Instead of debating for years (like other languages), zig just tries things out.

So did Rust pre-1.0

Stability guarantees are a pain in the neck. You can't just break other people's code willy nilly.

> This makes zig unique. It's fun to use and it stays fresh.

You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.

[alexrp]

Just on this point:

> You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.

The idea with making std.Io an interface is that we're not forcing you into using green threads - or OS threads for that matter. You can (and should) bring your own std.Io implementation for embedded targets if you need standard I/O.

[Ygg2]

Ok. But if your program assumes green threads and spawn like two million of them on target that doesn't support them, then what?

The nice thing about async is that it tells you threads are cheap to spawn. By making everything colourless you implicitly assume everything is green thread.

[interstice]

This is my favourite way to iterate, but the hard lesson is at some point after trying a bunch of things comes the Big Cleanup (tm). Is that a potential issue for this with Zig?

[BonusPlay]

From my perspective zig doesn't have "big cleanup" upfront. It's removing older features as it goes.

stdlib changes as it wants from version to version. So do language features. Since zig is pre-1.0, zig foundation isn't scared of breaking changes.

[SSLy]

0.16's IO API changes might be that cleanup.

[rurban]

> Instead of debating for years (like other languages), zig just tries things out.

Good

> Worst case you can always rollback changes.

No, you cannot. People will leave in masses. In perl they announced experiments with a mandatory use experimental :feature. You couldnt publish modules with those, or else you are at risk.

This made perl exciting and fresh. Python on the other hand constantly broke API's, and had to invent package version locks and "safe" venv's. Which became unsafe of course.

Languages and stdlib are not playgrounds. We see what came out of it with C and C++ with horrible mistakes getting standardized.

[ozgrakkurt]

I recently ditched zig because of this.

I thought it was stable enough initially but they completely broke fuzz testing feature and didn’t fix it.

Also build system API and some other APIs change and it is super annoying.

Find it much better to use c23 with _BitInt integers and some macros and context passing for error handling.

Also some things like stack traces were broken in small ways in zig. It would report wrong lines in stack traces when compiling with optimizations. Also wasn’t able to cleanly collect stack traces into strings in production build.

It is understandable that breaking APIs is good for development but in most cases new API isn’t that good anyway.

And recently saw they even moved the time/Instant API to some other place too. This kind of thing is just super annoying with seemingly no benefit. Could have left the same API there and re-used it from somewhere else. But no, have to make it “perfect”

[alexrp]

It sounds like you expected 1.0 stability from a language that isn't 1.0.

> I thought it was stable enough initially but they completely broke fuzz testing feature and didn’t fix it.

From the 0.14.0 release notes:

> Zig 0.14.0 ships with an integrated fuzzer. It is alpha quality status, which means that using it requires participating in the development process.

How could we possibly have been more explicit?

Fuzzing will be a major component of Zig's testing strategy in the long term, but we clearly haven't had the time to get it into shape yet. But we also didn't claim to have done!

> Also some things like stack traces were broken in small ways in zig. It would report wrong lines in stack traces when compiling with optimizations. Also wasn’t able to cleanly collect stack traces into strings in production build.

I mean, to be fair, most compiled languages can't give you 100% accurate source-level stack traces in release builds. But that aside, we have actually invested quite a lot of effort into std.debug in the 0.16.0 release cycle, and you should now get significantly better and more reliable stack traces on all supported platforms. If you encounter a case where you don't, file a bug.

> And recently saw they even moved the time/Instant API to some other place too. This kind of thing is just super annoying with seemingly no benefit. Could have left the same API there and re-used it from somewhere else. But no, have to make it “perfect”

I acknowledge that API churn can be annoying, but it would be weird not to aim for perfection prior to 1.0.

[ozgrakkurt]

Makes sense, that is fair.

I was a bit too frustrated with all these changes and zig wasn’t the right choice for my particular use case then.

[speed_spread]

Rust has stable vs nightly. Nightly tries things and makes no guarantees about future compatibilities. If you need code that builds forever, you stay on stable. There's no reason Zig couldn't have the same.