Zig 2024 roadmap

Posted Feb 5, 2024 10:22 UTC (Mon) by farnz (subscriber, #17727)
In reply to: Zig 2024 roadmap by roc
Parent article: Zig 2024 roadmap

comptime instead of generics is a non-starter, I suspect, since generics in Rust lay out data differently, not just change the code. But comptime instead of macros and some uses of traits would be extremely interesting to see; I suspect that there's a lot of cases where people currently have to write procmacros in Rust where comptime would be a good fit.

Zig 2024 roadmap

Posted Feb 5, 2024 13:44 UTC (Mon) by atnot (subscriber, #124910) [Link] (3 responses)

> comptime instead of generics is a non-starter, I suspect, since generics in Rust lay out data differently, not just change the code

You totally can do that! Zig and other languages with dependent-ish types generally have a unified type system for all types, including types themselves. In practical Zig terms, this means that you can't only return an integer from a comptime function, but the integer type itself, or a different type _depending_ on the arguments (that's where the term comes from), or an arbitrary struct type you just made, or a function, or anything really.

So in mathematical terms it's actually far more powerful than anything Rust has. Rust can do a few of these things as bespoke features but it's not a generalized system in the same way it is in dependently typed languages. This has its advantages and disadvantages, with dedicated syntax generally being more compact, readable and debuggable but also leaving weird incongruences between various parts of the language that are hard to solve, as Rust is experiencing.

It's been a pretty hip thing to experiment with somewhat recently (at least before effect systems really hit the scene) so I'm looking forward to seeing how Zig fares with it in a non-academic setting.

Zig 2024 roadmap

Posted Feb 5, 2024 19:02 UTC (Mon) by roc (subscriber, #30627) [Link] (2 responses)

What Zig does is not "dependent types" as in academia.

Zig 2024 roadmap

Posted Feb 5, 2024 20:16 UTC (Mon) by atnot (subscriber, #124910) [Link] (1 responses)

Yes, for anyone curious, one reason is that comptime isn't statically typed, it's dynamically typed but at compile time. For example, there is no way to write things like "comptime function that returns a function that returns either int or float", you can only write "comptime function that returns a function that returns some mystery surprise type". Like C++ templates, there's no type checking going on until after things have already been evaluated.

That said, you can do a lot of similar constructions and I think it faces a lot of similar issues regarding ergonomics when used in a non-fp language. Plus I think it does also demonstrate some of the benefits of having a single unified type system nicely without having to teach someone to read haskell-like syntax.

Zig 2024 roadmap

Posted Feb 5, 2024 20:35 UTC (Mon) by atnot (subscriber, #124910) [Link]

C++ templates are probably actually a good example in multiple ways here. Anyone really into their types would sneer at someone calling templates generics, they aren't really generics for similar reasons as comptime isn't dependent typing. But they're still extraordinarily popular and helpful, and they make it very easy to sell people on proper generics by pointing at them and saying "they're like that, but better".