upvote

points

by bruckie19 hours ago |
comments
upvoteby chaz7219 hours ago|
[-]
And they believe Zig comptime wouldn’t do that? For the same inputs? I’d love an example.
reply
upvoteby vlovich12318 hours 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.

Not saying I agree though - those can happen anyway when you run on two different machines anyway.

reply
upvoteby dnautics4 hours ago|
parent|
next
[-]
Zig Comptime is softfloat
reply
upvoteby chaz7217 hours ago|
parent|
prev|
next
[-]
I get it now. Important things but not things that I use often - hopefully addressed by 1.0.
reply
upvoteby weinzierl16 hours ago|
parent|
[-]
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.

reply
upvoteby chaz7216 hours ago|
parent|
next
[-]
I hear you but I’m not sure it’s as dramatic as that, it’s also been quite predictable in my use over the last few years since I haven’t happened to use floating point or different endianness.
reply
upvoteby vlovich12316 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby tcfhgj15 hours ago|
parent|
[-]
reproducible builds
reply
upvoteby vlovich12312 hours ago|
parent|
[-]
build.rs checkmate
reply
upvoteby tcfhgj10 hours ago|
parent|
[-]
not mandatory
reply
upvoteby vlovich1239 hours ago|
parent|
[-]
Neither is using const
reply
upvoteby tcfhgj9 hours ago|
parent|
[-]
correct, but it is desirable
reply
upvoteby smj-edison15 hours ago|
parent|
prev|
[-]
Doesn't comptime run under the target's float and endianness semantics? I need to check, but I believe they emulate the target when evaluating.
reply
upvoteby vlovich1238 hours ago|
parent|
[-]
Endianness yes, but float no. They just force software ieee754. It gives you exact bit accuracy on all build machines but it results in math that would differ between build time and run time depending if the function is evaluated as const or not
reply
upvoteby weinzierl18 hours ago|
parent|
prev|
next
[-]
sin(x) can produce different results at comptime and runtime. In Rust there is no sin(x) at comptime for precisely this reason.
reply
upvoteby chaz7217 hours ago|
parent|
[-]
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 and I have also read they are doing some other work on floating point that will hopefully address other cross-platform inconsistencies.
reply
upvoteby 18 hours ago|
parent|
prev|
[-]
deleted
reply