4 ms·

Really feels like the project is spreading itself too thin. There are existing community build Package Managers for Zig. It's weird to start replacing things th

by j-pb 4y ago

Really feels like the project is spreading itself too thin. There are existing community build Package Managers for Zig. It's weird to start replacing things that are good enough™, while core stuff like the languag and compiler is not even ready for hobby projects. The zig folks should really have this talk running on a loop: https://m.youtube.com/watch?v=lw6TaiXzHAE https://m.youtube.com/watch?v=lw6TaiXzHAE

kristoff_it 4y ago
It was planned from the start to have an official package manager and have it be part of the main compiler executable. > compiler is not even ready for hobby projects Depends on the kind of hobby projects you have. We held a conference with two workshops a while ago and everything went great, just as a data point :^)
- 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

kristoff_it 4y ago

It was planned from the start to have an official package manager and have it be part of the main compiler executable. > compiler is not even ready for hobby projects Depends on the kind of hobby projects you have. We held a conference with two workshops a while ago and everything went great, just as a data point :^)

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/