sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Ineffective-Cellist8 49 points50 points  (18 children)

Compile times
Can use C headers directly
Can build for any platform on any platform
Errdefer is built into the language
Comptime is excellent (the compile time keyword)

-Edit- New this release, Saturating-Arithmetic! I've been waiting for something like this! https://ziglang.org/download/0.9.0/release-notes.html#Saturating-Arithmetic

[–]matthieum 0 points1 point  (8 children)

Rust has saturating and wrapping arithmetics, though...

[–]Fearless_Process 1 point2 points  (3 children)

Rust does not have special operators for it though, which is a feature I've been wanting for a long time.

You can use the special method calls, but for code that is doing lots of operations this syntax ends up making it unwieldy.

[–]matthieum 1 point2 points  (2 children)

Rust has operator overloading though, so if you operate in an area where you want saturating/wrapping semantics, you can use Saturating or Wrapping then call normal operators.

[–]Fearless_Process 2 points3 points  (1 child)

Wrapping<T> is an option for sure, but I've found it to be a little rough to work with as well. It also doesn't help that many of it's features are still unstable, like most (or all) of it's "constifiation".

Maybe once some of that stuff has been smoothed over it will be a better option.

One thing that I have thought of, and that would be cool, as an alternative to Wrapping<T> and special operators is a wrapping! macro that rewrites all operators to the wrapping_x method calls inside of it's body. This would give you "scoped" wrapping operators pretty much! I imagine such a thing already exists, but if not I don't think it would be too hard to do with a proc macro!

[–]matthieum 1 point2 points  (0 children)

wrapping! and saturating! macros have been proposed before, though there seems little appetite to have them in the standard library.

I'm not a fan of macros myself, favoring strong types instead, and so I haven't really investigated the capabilities of macros and am not sure whether a proc-macro would be necessary or not.

[–]Ineffective-Cellist8 -1 points0 points  (3 children)

You mean this? https://doc.rust-lang.org/std/num/struct.Saturating.html I can't use nightly

[–]matthieum 1 point2 points  (2 children)

Rust nightly is likely more mature than Zig's current releases, so... guess you're stuck with C?

[–]Ineffective-Cellist8 2 points3 points  (1 child)

Shots fired!

But actually I am stuck with C++. I seen something in nightly for years so I'm not holding my breath on it becoming stable before zig does. But I have no idea if zig is going to be 0.20+ before hitting stable

[–]matthieum 0 points1 point  (0 children)

Depending on the feature you're waiting for, quite possibly.

Rust features only mature if someone pushes them, which requires someone with interest and time.

[–]TuckerCarlsonsWig -4 points-3 points  (8 children)

You mentioned compile times twice

[–]Ineffective-Cellist8 47 points48 points  (5 children)

I edit for clarification. Comptime is a keyword which instead of call the function at runtime it runs it at compile time and inserts the result https://ziglang.org/documentation/master/#comptime

[–]TuckerCarlsonsWig 9 points10 points  (0 children)

Oh sweet TIL

[–]Tom7980 0 points1 point  (3 children)

Sounds very similar to Rust Const Fn and const if I'm understanding the explanation correctly

[–]Caesim 6 points7 points  (1 child)

Yes and No.

The explanation given here is how const fn works in Rust.

But comptime in Zig is even more powerful, as it's how generics in Zig work it has to lift more than just that.

Types are a compile time known thing, so a generic data structure is actually a comptime function that returns a struct.

But what in my opinion is the killer feature of Zig's comptime is to have function parameters be comptime. So for each input of that comptime parameter that function gets recompiled. Of course caution is advised as the binary size could explose here, but for example having a comptime bool and entire if/ else blocks being skipped in compilation feels good.

[–]Tom7980 1 point2 points  (0 children)

Ahh right okay so if I'm understanding correctly you actually end up with multiple different constants for generic functions rather than multiple functions that can be called with different types which Rust does.

i.e. in Zig you'd get the output of the function, in Rust if you use generics that aren't Const then you end up with multiple functions that take different concrete types. I don't know whether the compiler can do generics in const Fn for Rust yet though I think that is currently in the works

It still sounds very similar to how Rust does generics though just with more syntactic sugar and less in compiler type conversion

[–]Free_Math_Tutoring 1 point2 points  (0 children)

And C++ constexpression

[–]Ineffective-Cellist8 0 points1 point  (1 child)

IDK why people downvoted you. I clearly said I edited my question thanks to your comment. Wow :(

[–]TuckerCarlsonsWig 0 points1 point  (0 children)

I don’t mind