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

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

[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”

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