5 ms·

The issues with Zig is not getting something off the ground in a weekend, but maintaining things over multiple weekends, without some bike-shed-change like `@ma

by j-pb 4y ago

The issues with Zig is not getting something off the ground in a weekend, but maintaining things over multiple weekends, without some bike-shed-change like `@maximum` vs. `@max`, some compiler bug for a basic feature, or some std.heap API change breaking your code. Zig really needs some subset carved out and some stability guaranteed placed on that so that innovation can't only happen by the core team, but also by the community. Rust does a much better job in that regard, by marking at least some things as stable. It's extremely hard to contribute to the ecosystem when everything is build on sand without at least some save haven of stability. E.g. if Zig had a `loop` statement like Rust, that could be marked stable from day one, because the syntax surface is so small. Same goes for extern structs, because they are already defined in terms of C ABI.

skribanto 4y ago
Well Rust has already passed 1.0, so it makes sense that it's more stable. Rust is also twice the age of Zig.
- j-pb 4y ago
  I'm not arguing that Zig should have the same stability as Rust, which would be unreasonable. My point is that there is no concept of stability at all. Zig currently treats "async" as the same kind of unstable as "for" and "@max". I don't mind "for" being unstable, the new syntax IS much better than the old one. But by also providing for example a stable "loop { break; }" the language would empower people from the community to focus on building tooling by making the tradeoff of restricting themselves to a more more cumbersome, sugarless, and minimalistic subset.
kristoff_it 4y ago
> Zig really needs some subset carved out and some stability guaranteed placed on that so that innovation can't only happen by the core team, but also by the community. Your comment makes sense, but this is just not the model that we follow. I think the time for more contributions from the outside world will come (and the pkg manager is a big step in that direction), but when it comes to the core language it's a different story. In case you haven't read it, I blogged a while ago about how decision-making happens in the Zig project: https://kristoff.it/blog/interfacing-with-zig/ https://kristoff.it/blog/interfacing-with-zig/

by j-pb 4y ago

skribanto 4y ago

Well Rust has already passed 1.0, so it makes sense that it's more stable. Rust is also twice the age of Zig.

j-pb 4y ago
I'm not arguing that Zig should have the same stability as Rust, which would be unreasonable. My point is that there is no concept of stability at all. Zig currently treats "async" as the same kind of unstable as "for" and "@max". I don't mind "for" being unstable, the new syntax IS much better than the old one. But by also providing for example a stable "loop { break; }" the language would empower people from the community to focus on building tooling by making the tradeoff of restricting themselves to a more more cumbersome, sugarless, and minimalistic subset.

kristoff_it 4y ago

> Zig really needs some subset carved out and some stability guaranteed placed on that so that innovation can't only happen by the core team, but also by the community. Your comment makes sense, but this is just not the model that we follow. I think the time for more contributions from the outside world will come (and the pkg manager is a big step in that direction), but when it comes to the core language it's a different story. In case you haven't read it, I blogged a while ago about how decision-making happens in the Zig project: https://kristoff.it/blog/interfacing-with-zig/ https://kristoff.it/blog/interfacing-with-zig/