‹ BackHN Continuity

Thread

What Zig felt like, coming from Rust

282 points · 351 comments · ksec

  1. weinzierl · · focus · HN ↗
    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.

    1. chaz72 · · focus · HN ↗
      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?
      1. bruckie · · focus · HN ↗
        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.
        1. chaz72 · · focus · HN ↗
          And they believe Zig comptime wouldn’t do that? For the same inputs? I’d love an example.
          1. vlovich123 · · focus · HN ↗
            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.

            1. chaz72 · · focus · HN ↗
              I get it now. Important things but not things that I use often - hopefully addressed by 1.0.
              1. weinzierl · · focus · HN ↗
                I'm not sure there is something to be addressed. Zig has just a different approach and Zig people different expectations.

                In Rust we can expand what is possible at compile time without breaking existing code because we took a very careful approach only stabilizing what we are sure about. Some things will probably never be possible at compile time in Rust.

                Zig is much more powerful but that also means they cannot take stuff away without breaking existing code and making comptime more restricted. So it is unlikely Zig will ever become like Rust in that regard, but that is ok - just different approaches.

                1. vlovich123 · · focus · HN ↗
                  I think the Rust approach is incorrect - if the runtime behavior can change based on the machine that the code gets run on, why is it so important the build time behavior has such a restrictive definition? Especially considering build.rs can be used to bypass that definition anyway. It feels like a weird cut to make that I can’t figure out the understanding for. It feels like it inherited the const philosophy of c++11 without reexamining if it’s actually a good idea.
                  1. tcfhgj · · focus · HN ↗
                    reproducible builds
                    1. vlovich123 · · focus · HN ↗
                      build.rs checkmate
                      1. tcfhgj · · focus · HN ↗
                        not mandatory
                        1. vlovich123 · · focus · HN ↗
                          Neither is using const
                          1. tcfhgj · · focus · HN ↗
                            correct, but it is desirable
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.