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.

▲

chaz72 an hour ago | parent | next [-]

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?

▲

weinzierl 10 minutes ago | parent | next [-]

Yes. For example in Rust it took a long time for floating point operations to be available at compile time and even now only a subset is. The reason is that a lot of energy and thought went into the issue of producing identical output (and what identical precisely means ) even when compilation is on a different processor than where the target runs.

As far as I know this is not a concern for Zig comptime.

▲

bruckie an hour ago | parent | prev [-]

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 41 minutes ago | parent [-]

And they believe Zig comptime wouldn’t do that? For the same inputs? I’d love an example.

	▲	vlovich123 a few seconds ago \| parent \| next [-]
		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.
	▲	4 minutes ago \| parent \| prev \| next [-]
		[deleted]
	▲	weinzierl 5 minutes ago \| parent \| prev [-]
		sin(x) can produce different results at comptime and runtime. In Rust there is no sin(x) at comptime for precisely this reason.

▲

LoganDark an hour ago | parent | prev [-]

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.

▲

tialaramex 19 minutes ago | parent | next [-]

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 12 minutes ago \| parent [-]
		> 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!`.

▲

vlovich123 36 minutes ago | parent | prev [-]

There’s a few comptime crates out there. Crabtime is iirc the most mature and popular

▲

LoganDark 31 minutes ago | parent [-]

I don't think I would ever depend on something like that for a library crate. There's enough syn+proc_macro2 pollution in the ecosystem already.

	▲	tialaramex 13 minutes ago \| parent [-]
		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.