alt Hacker NewsInstead 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.
Replies
> 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).
> 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.
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.
> 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.
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?
> 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.
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.