9 ms·

Two additional points: 1. Tooling (as an extension to the mentioned IDE support point). Zig and Rust are both praised for their tooling and I think rightfully

Two additional points: 1. Tooling (as an extension to the mentioned IDE support point). Zig and Rust are both praised for their tooling and I think rightfully so. The C/C++ interop story and the cross-compiling story in Zig are great. From the standpoint of a working practitioner though I think Rust is way ahead. Not surprising given that Zig is much younger, but something to keep in mind. 2. Compile Time Stuff: Here Zig is praised and Rust not so much. I think this is undeserved. Rust has much higher aspirations for their compile time features, namely that outcome must be identical regardless when the code runs. This is a very useful property but makes the task much harder and fundamentally incomparable with Zig comptime.

LoganDark 9d ago
Zig comptime feels easier and more effective in practice. I've had some fun const evaluating some stuff in Rust, but I needed to use a bunch of annoying imperative hacks because so much of the functional stuff wasn't supported in const context back then. It's probably a bit better these days. For one of my crates I needed to have a build script make a bunch of lookup tables as separate files for me to `include_bytes!` because at the time I couldn't generate a bunch of floating point conversions in const.
- vlovich123 9d ago
  There’s a few comptime crates out there. Crabtime is iirc the most mature and popular
  - LoganDark 9d ago
    I don't know if I would ever depend on something like that for a library crate. There's enough syn+proc_macro2 pollution in the ecosystem already.
    - tialaramex 9d ago
      It does seem like maybe a crate with convenience macros so you can get a `&'static [Foo; N/size(Foo)]` rather than `&'static [u8; N]` and maybe even a delicious compile time "Hey jerk, that's not a valid Foo, you screwed up" if appropriate from your pre-baked data files, would be nice regardless of having more constant eval.
      - deleted 9d ago
        [deleted]
- tialaramex 9d ago
  Certainly every new Rust release tends to have either new things which were stabilized as const on day one, or things which already existed but now have stable const. The biggest constraint today on Rust's constant evaluation compared to where you'd expect is that trait implementations can't ever be constant, this obviously means you can't call SomeTrait::function in your constant, even if you can see the implementation of SomeTrait::function and if it were not a trait it'd obviously be constant -- but it also means sugar like Rust's for loop, which de-sugars into trait invocations, can never be constant today. I think we can expect that to get fixed in the relatively near future, but I'd have said that last year too so what do I know. If you have C++ experience you'd probably want a lot more. C++ is allowed to allocate inside constant evaluation, and I believe in C++ 26 it's now even allowed to persist the allocation to runtime rather than being required to always clean up during compilation, so that's a much bigger set of crazy things you can do at compile time.
  - LoganDark 9d ago
    > it also means sugar like Rust's for loop, which de-sugars into trait invocations, can never be constant today. Yep, that was my annoyance. Const allocation is possible in Rust as an unstable feature. Not sure if you can persist it to runtime, though you can persist a reference which will become a static reference. I think it being unstable is why I needed `include_bytes!`.
    - estebank 9d ago
      FWIW const traits are progressing quite nicely. It will also allow for Default to be used in const context, which is quite handy (and will integrate nicely with default field values, which only allows consts today in nightly).
chaz72 9d ago
Are you saying that you think that Zig does not produce identical outcomes for comptime code regardless of when the code runs? What do you mean?
- bruckie 9d ago
  I assumed that it meant that if you ran code at compile time or at runtime, the results should be exactly the same given the same inputs.
  - chaz72 9d ago
    And they believe Zig comptime wouldn’t do that? For the same inputs? I’d love an example.
    - weinzierl 9d ago
      sin(x) can produce different results at comptime and runtime. In Rust there is no sin(x) at comptime for precisely this reason.
      - chaz72 9d ago
        Interesting, I hadn’t run across that but that’s probably just my problem domain. I did find this bug that looks like it was resolved a year ago https://github.com/ziglang/zig/issues/24184 https://github.com/ziglang/zig/issues/24184 and I have also read they are doing some other work on floating point that will hopefully address other cross-platform inconsistencies.
    - deleted 9d ago
      [deleted]
    - vlovich123 9d ago
      Traditional stuff in this space are: * floating point differences between the build machine and the target. By far the most common * endiannes - code assumes little median runs on big endian There’s other more subtle issues that can crop up but those are the big two. Not saying I agree though - those can happen anyway when you run on two different machines anyway.

LoganDark 9d ago

Zig comptime feels easier and more effective in practice. I've had some fun const evaluating some stuff in Rust, but I needed to use a bunch of annoying imperative hacks because so much of the functional stuff wasn't supported in const context back then. It's probably a bit better these days. For one of my crates I needed to have a build script make a bunch of lookup tables as separate files for me to `include_bytes!` because at the time I couldn't generate a bunch of floating point conversions in const.

vlovich123 9d ago
There’s a few comptime crates out there. Crabtime is iirc the most mature and popular
- LoganDark 9d ago
  I don't know if I would ever depend on something like that for a library crate. There's enough syn+proc_macro2 pollution in the ecosystem already.
  - tialaramex 9d ago
    It does seem like maybe a crate with convenience macros so you can get a `&'static [Foo; N/size(Foo)]` rather than `&'static [u8; N]` and maybe even a delicious compile time "Hey jerk, that's not a valid Foo, you screwed up" if appropriate from your pre-baked data files, would be nice regardless of having more constant eval.
    - deleted 9d ago
      [deleted]
tialaramex 9d ago
Certainly every new Rust release tends to have either new things which were stabilized as const on day one, or things which already existed but now have stable const. The biggest constraint today on Rust's constant evaluation compared to where you'd expect is that trait implementations can't ever be constant, this obviously means you can't call SomeTrait::function in your constant, even if you can see the implementation of SomeTrait::function and if it were not a trait it'd obviously be constant -- but it also means sugar like Rust's for loop, which de-sugars into trait invocations, can never be constant today. I think we can expect that to get fixed in the relatively near future, but I'd have said that last year too so what do I know. If you have C++ experience you'd probably want a lot more. C++ is allowed to allocate inside constant evaluation, and I believe in C++ 26 it's now even allowed to persist the allocation to runtime rather than being required to always clean up during compilation, so that's a much bigger set of crazy things you can do at compile time.
- LoganDark 9d ago
  > it also means sugar like Rust's for loop, which de-sugars into trait invocations, can never be constant today. Yep, that was my annoyance. Const allocation is possible in Rust as an unstable feature. Not sure if you can persist it to runtime, though you can persist a reference which will become a static reference. I think it being unstable is why I needed `include_bytes!`.
  - estebank 9d ago
    FWIW const traits are progressing quite nicely. It will also allow for Default to be used in const context, which is quite handy (and will integrate nicely with default field values, which only allows consts today in nightly).

chaz72 9d ago

Are you saying that you think that Zig does not produce identical outcomes for comptime code regardless of when the code runs? What do you mean?

bruckie 9d ago
I assumed that it meant that if you ran code at compile time or at runtime, the results should be exactly the same given the same inputs.
- chaz72 9d ago
  And they believe Zig comptime wouldn’t do that? For the same inputs? I’d love an example.
  - weinzierl 9d ago
    sin(x) can produce different results at comptime and runtime. In Rust there is no sin(x) at comptime for precisely this reason.
    - chaz72 9d ago
      Interesting, I hadn’t run across that but that’s probably just my problem domain. I did find this bug that looks like it was resolved a year ago https://github.com/ziglang/zig/issues/24184 https://github.com/ziglang/zig/issues/24184 and I have also read they are doing some other work on floating point that will hopefully address other cross-platform inconsistencies.
  - deleted 9d ago
    [deleted]
  - vlovich123 9d ago
    Traditional stuff in this space are: * floating point differences between the build machine and the target. By far the most common * endiannes - code assumes little median runs on big endian There’s other more subtle issues that can crop up but those are the big two. Not saying I agree though - those can happen anyway when you run on two different machines anyway.