3 ms·

Zig is a pre-1.0 language while Rust is post-1.0. This alone is settles which one to pick for may developers. The library support is probably favours Rust too.

Zig is a pre-1.0 language while Rust is post-1.0. This alone is settles which one to pick for may developers. The library support is probably favours Rust too. Rust build times are much slower than Zig, I get that, but I rarely optimize software for build times.

drdexebtjl 3mo ago
Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes. Nowadays when you can just point an agent at release notes and have it update everything, I actually prefer not having to wait through rare major releases to get new language features.
- afdbcreid 3mo ago
  > Nowadays when you can just point an agent at release notes and have it update everything Except that means that not only you lose compiler bugfixes, you also pretty much has no access to the ecosystem. For most production codebases, this is a deal breaker.
- rwz 3mo ago
  > they want to be able to make breaking language changes That sounds like it's not ready for production to me.
  - drdexebtjl 3mo ago
    I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about. To me it is not much different from Lua, which despite being on 5.x for decades, makes breaking changes on minor releases (because it predates SemVer). I also don’t see it being much different from any other language or language runtime that has a major release every year. It’s fine to update at your own pace.
    - uaksom 3mo ago
      > I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about. I did, and I immediately found this in the latest release: https://ziglang.org/download/0.16.0/release-notes.html#IO-as-an-Interface https://ziglang.org/download/0.16.0/release-notes.html#IO-as... That seems like it would require changing a lot of code. Calling it "production ready" is dishonest at best
      - drdexebtjl 3mo ago
        Not really. It’s find and replace work. If by production-ready you mean you can forever avoid changing code you wrote 8 months ago, sure, pick something else. To me production-ready means it can be trusted to power production workloads, has all tooling I need, and has a consistent long-term vision. Zig ticks all the boxes.
        uaksom 3mo ago
        Changing core features every few months doesn't seem very consistent...
- Aurornis 3mo ago
  > Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes. This is a solved problem in other projects. Either use the version numbers as intended and bump the major version number on breaking changes, or use Rust-style editions to opt in to the newer versions of the changes. Calling a project production-ready but keeping the version number below 1.0 and saying breaking changes are expected is a tired game. We've seen it backfire across a number of language projects like Elm, where the exact same claim was used to both encourage people to use it and then blame them when it backfired. If it's production ready, go to 1.0 and then follow semver for breaking changes. I don't care if we get to Zig v73.2.0 as a result. At least we can see from a glance which versions need to be checked for breaking changes.
  - drdexebtjl 3mo ago
    [dead]
  - em-bee 3mo ago
    languages ideally should not have breaking changes ever. on the other hand, a language with frequent breaking changes should not be considered production ready. people are of course free to live on the edge, and if someone decided that zig is good enough and they are not bothered by breaking changes then they are free to use it for their production system, but that doesn't mean it's ready for everyone. so i prefer the zig approach.
    - bsder 3mo ago
      > languages ideally should not have breaking changes ever. I disagree MIGHTILY. This is how you wind up with C++ and Java. Languages need to be able to remove features to stay coherent. Occasionally, you get things wrong, it takes time to figure that out, and that's just the way life is.
      - em-bee 3mo ago
        different preferences i guess. i much prefer language stability. the idea that i should have to test my code with every python version out there for example is disturbing, but there are tools to do exactly that. they should not be needed.
audunw 3mo ago
That’s totally reasonable. But while each minor version has breaking change, a minor version release itself is generally fairly stable and useable. There are solid production software which is already using Zig, like TigerBeetle and Ghostty/libghostty. I am waiting for (near) 1.0 myself before doing anything major with it. But that’s mainly because I want at least the async IO stuff to be settled for my use cases.
LAC-Tech 3mo ago
Counter Argument - with Zig it's perfectly viable to make programs using just the standard library. You have json serde, zon (zig object notation) serde, system functions (ie libc/rustix equivalent), random number generators... all without a single dependency.

drdexebtjl 3mo ago

Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes. Nowadays when you can just point an agent at release notes and have it update everything, I actually prefer not having to wait through rare major releases to get new language features.

afdbcreid 3mo ago
> Nowadays when you can just point an agent at release notes and have it update everything Except that means that not only you lose compiler bugfixes, you also pretty much has no access to the ecosystem. For most production codebases, this is a deal breaker.
rwz 3mo ago
> they want to be able to make breaking language changes That sounds like it's not ready for production to me.
- drdexebtjl 3mo ago
  I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about. To me it is not much different from Lua, which despite being on 5.x for decades, makes breaking changes on minor releases (because it predates SemVer). I also don’t see it being much different from any other language or language runtime that has a major release every year. It’s fine to update at your own pace.
  - uaksom 3mo ago
    > I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about. I did, and I immediately found this in the latest release: https://ziglang.org/download/0.16.0/release-notes.html#IO-as-an-Interface https://ziglang.org/download/0.16.0/release-notes.html#IO-as... That seems like it would require changing a lot of code. Calling it "production ready" is dishonest at best
    - drdexebtjl 3mo ago
      Not really. It’s find and replace work. If by production-ready you mean you can forever avoid changing code you wrote 8 months ago, sure, pick something else. To me production-ready means it can be trusted to power production workloads, has all tooling I need, and has a consistent long-term vision. Zig ticks all the boxes.
      - uaksom 3mo ago
        Changing core features every few months doesn't seem very consistent...
Aurornis 3mo ago
> Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes. This is a solved problem in other projects. Either use the version numbers as intended and bump the major version number on breaking changes, or use Rust-style editions to opt in to the newer versions of the changes. Calling a project production-ready but keeping the version number below 1.0 and saying breaking changes are expected is a tired game. We've seen it backfire across a number of language projects like Elm, where the exact same claim was used to both encourage people to use it and then blame them when it backfired. If it's production ready, go to 1.0 and then follow semver for breaking changes. I don't care if we get to Zig v73.2.0 as a result. At least we can see from a glance which versions need to be checked for breaking changes.
- drdexebtjl 3mo ago
  [dead]
- em-bee 3mo ago
  languages ideally should not have breaking changes ever. on the other hand, a language with frequent breaking changes should not be considered production ready. people are of course free to live on the edge, and if someone decided that zig is good enough and they are not bothered by breaking changes then they are free to use it for their production system, but that doesn't mean it's ready for everyone. so i prefer the zig approach.
  - bsder 3mo ago
    > languages ideally should not have breaking changes ever. I disagree MIGHTILY. This is how you wind up with C++ and Java. Languages need to be able to remove features to stay coherent. Occasionally, you get things wrong, it takes time to figure that out, and that's just the way life is.
    - em-bee 3mo ago
      different preferences i guess. i much prefer language stability. the idea that i should have to test my code with every python version out there for example is disturbing, but there are tools to do exactly that. they should not be needed.

audunw 3mo ago

That’s totally reasonable. But while each minor version has breaking change, a minor version release itself is generally fairly stable and useable. There are solid production software which is already using Zig, like TigerBeetle and Ghostty/libghostty. I am waiting for (near) 1.0 myself before doing anything major with it. But that’s mainly because I want at least the async IO stuff to be settled for my use cases.

LAC-Tech 3mo ago

Counter Argument - with Zig it's perfectly viable to make programs using just the standard library. You have json serde, zon (zig object notation) serde, system functions (ie libc/rustix equivalent), random number generators... all without a single dependency.