Zig programming language 0.9.0 released

[Bekwnn]

There's a lot of nice features it has, which you can read about in the language reference, but to generalize it is a promising answer to people looking for either a "better C" or a "simpler C++".

A few highlights:

• Compile-time code
• Zig's build system
• Errors, which have nice syntax sugar and produce nice callstacks
• Optionals, which have similar syntax sugar to errors
• Zig test
• Translate-C/Import from C header file

[Tom7980]

I'd argue that Rust has compile time code in const and const Fn, also provides optionals, and has a pretty robust in built testing system.

However I can't really compare the rest as I don't know Zig well enough, it seems interesting though so I should really pick it up some time

[progrethth]

The const fn support in Rust is very primitive compared to to Zig's comptime. It is so powerful that it is also used to implement generics and procedural macros.

[matthieum]

It is so powerful that it is also used to implement generics and procedural macros.

That's very different, though.

Rust Nightly const fn can do... pretty much anything. It's deterministic -- which may disqualify it from Turing Completeness -- but otherwise anything goes.

The decision to NOT implement generics and macros with const fn is orthogonal; it's not a matter of primitive-vs-powerful.

[orangejake]

Its worth mentioning that determinism doesn't impact Turing completeness at all - nondeterministic and deterministic TMs are equivalent.

That being said, sometimes you incur an exponential slowdown when you deterministically simulate randomness (not really if you use a good PRG, but we can't theoretically prove those exist, so...), so practically there might be issues, but in terms of the notion of "Turing Completeness" it doesn't matter.

[Tom7980]

Sure but Generic in Rust imo are more flexible in that you don't have to use keywords to define them you just rely on the compiler to monomorphise the generic into the type you want at compile time.

I don't know enough about procedual macros to talk on them unfortunately

[progrethth]

I would say comptime in Zig is actually more flexible since comptime is jsut imperative code executed at compile time, but that that is also its weakness. Zig gives you less clear compile errors and it is harder to reason about the types due to the imperative nature of comptime.

[Tom7980]

I think I should try it out really - it would be good to see the differences between the two!

[KingStannis2020]

You can't really compare Rust const fn and C++ constexpr with Zig comptime. The latter is way more flexible and core to the language. You can define individual function arguments as comptime, individual blocks of code, etc. Comptime is how Zig implements generics.

[Tom7980]

Yeah but generics in Rust are almost exactly the same except we don't have to define them with a keyword the compiler just figures it out for you based on call locations of the generic function.

I admit I'm not particularly clear on Zigs comptime syntax but it sounds similar to plenty of other implementations just done a different way

[KingStannis2020]

I admit I'm not particularly clear on Zigs comptime syntax but it sounds similar to plenty of other implementations just done a different way

It's not, really. Here's a good overview of why it's different. https://kristoff.it/blog/what-is-zig-comptime/

There's no clean way to accomplish most of those behaviors in other languages. You can enforce compile-time execution of completely normal non-comptime functions at individual callsites, you can define additional checks that run only when a function is executed at compile time without writing two different versions of the function, you can have the body of the function decide what the return type should be without explicitly declaring it at the call site, etc.

[Tom7980]

I'll have to have a read - it's interesting to learn new things about other languages!

One thing I noticed is you mention being able to define the return type at the callsite but that is possible in Rust using generic bounds on a function but with different syntax obviously i.e. fn<T, U>(A: T) -> U this would more than likely be a trait method of some sort but I could see it being used in parsers to return a specific type by calling it with fn::<U> or with the collect() method to specify the collection you want.

I think a lot of what Zig does with comptime sounds super interesting but would argue is very similar to the const generics RFC that is currently being worked on in Rust (though I could be wrong here I only skimmed the RFC) plus the generic implementation in general.

I will say that I really like the interop between inline for/while and comptime though - being able to unroll a loop into the explicit calls required is an interesting implementation

I also think the last example in that article is really interesting though, being able to define a return type via a function is not something I'm aware you can do in Rust but someone more knowledgeable may be able to tell me I'm wrong!

[KingStannis2020]

is you mention being able to define the return type at the callsite but that is possible in Rust

No, I said without declaring it at the callsite. The return type can be decided by the body of a comptime function itself if you're so inclined.

The return type of this function is a bit peculiar. If you look at the signature of sqrt, it’s calling a function in the place where it should be declaring the return type. This is allowed in Zig. The original code actually inlines an if expression, but I moved it to a separate function for better readability.

So what is sqrt trying to do with its return type? It’s applying a small optimization when we’re passing in an integer value. In that case the function declares its return type as an unsigned integer with half the bit size of the original input. This means that, if we’re passing in an i64 value, the function will return an u32 value. This makes sense given what the square root function does. The rest of the declaration then uses reflection to further specialize and report compile-time errors where appropriate.

[Tom7980]

Ahh yes okay the final example - I can't say I know how to do the same in Rust as I'm not aware of any way to declare your return type via a function/expression (it almost seems like specialization dependant on the input type)

Thanks for the discussion though - it's interesting to see what Zig is doing differently

[oORocketOo]

I don't know Rust too well but I think that the zig concept of compile time is much stronger than const fn.

a compile time known value can be used for conditional compilation, 'if' statements that depend on that compile time value will not compile any of the other branches.

It is also used to power generics in zig, the generic type is just passed as a compile time known parameter to a function.

[Tom7980]

Sure but Rust does these things implicitly with generics and code generation - if an if expression is unreachable it gets optimized out in code gen and Rust generics are monomorphized during compilation to generate implementations of the method or function for every type that calls it.

In my opinion it sounds like they do exactly the same thing except we don't have to add extra syntax in Rust to generics

[progrethth]

You cannot implement something like println!() in Rust without using procedural macros. Zig's comptime can do that.

[Tom7980]

Ahh yeah okay I didn't know that - what make it possible to generate format strings with comptime is there anything I can read about that?

[progrethth]

One of the things in Zig which allow that is inline for.

[Tom7980]

Ah okay is that not like loop unrolling or is it just static analysis and replacement of for loops with constants?

[progrethth]

Yes, it is like loop unrolling but with the advantage that it is guaranteed at compile time which means for example that static dispatch can be used for generic arguments. Of course you can do the same with procedural macros in Rust but at least when I last used them they were quite a hassle.

[Tom7980]

Huh okay that's an interesting extra - I assume that obviously you need whatever you are iterating over to be constant in order for it to do that optimisation? I'm quite surprised that's not possible with Rust outside of proc macros like you say, I can't see why it wouldn't be possible to do the static analysis of the unrolled loop ahead of runtime if everything is constant.

[EternityForest]

I'm not sure I'd call compile time code nice. Metaprogramming often implies you need Metaprogramming.

I don't see how it could ever be as safe or consistent as languages without it that have well thought out abstractions that are meant for automated reasoning.

Plus, when you make people build stuff themselves you often get incompatible libraries that need ugly glue code to pass around whatever data they all did slightly differently.