the blog post mentions the zig team is working on a comptime debugger, i cant find any information on this
Associated Hacker News discussion: Zig's Comptime Is Bonkers Good | Hacker News
I’ve read from twitter influencers that
clang metaprogam.c -o meta && meta.exe
clang program.c -o final
is just as good, but honestly to me that just needlessly complex. Zigs comptime is so good because it’s easy and seamless to use.
Who honestly wakes up in the morning and chooses textual generation of a program as their first choice of comptime programming?
I’m sure I would do it in certain scenarios; I might even do it with Zig at some point. But it would have to be for a massive hurdle. I wouldn’t do it for something simple like the length of an array. I would do it for parsing a protobuf type and spitting out a Zig implementation, for example. But with comptime, there’s typically no need to make a Zig code generator. You can just write in the language as normal.
As always the top comment is something about how the type constraints of generic functions aren’t declaratively put in the function signature, and that somehow makes generic APIs hard to reason about. It’s my understanding that the current system, which is duck typed, significantly reduces both language and compiler implementation complexity when dealing with generics. It also adds a bit of friction when creating generic APIs. I think more declarative and complex systems that allows people to define all their invariants in the type system (as seen in other languages) would just encourage people to write more generic code, which is a bad thing! Generic code compiles slower and even with more “expressive” type systems is still often hard to reason about.
I have come to the conclusion that most of those comments come from those whom have never written a line of Zig in their lives. Their arguments are always some abstraction or philosophical nonsense of general design principle, none of which is even relevant to Zig or its implementation of the thing they are attempting to sound knowledgeable about. They read an article about something, conclude that they are now experts on the matter, despite not understanding it or having any experience with it whatsoever, and then declare themselves as an authority on the matter. Basically the internet in a nutshell, I guess?
I agree with you and I’m very happy with how Zig is, but I have a big complaint about anytype I really think it’s very unreadable, and whilst I wouldn’t ask for type constrained generic per say, I think a better solution ought to be found than anytype. Because just like you mentioned, one of the core feature of Zig, is it’s careful design and use of friction to balance the language idioms. In Zig it’s often quite easy to get things done, even when you want to do something generic, but you still have the friction of checking things properly at comptime not so much that you would necessarily avoid it, but enough to make you think twice. The only exception is with anytype it’s just very easy and convenient to write, and although it’s being used pretty responsibly for now, It’s still too easy to write and often times too hard to reason about, especially when you have multiple of them in a function signature. There is a proposal to change anytype with infer T which would already be a step in the right direction but still, I think there is some room for improvement without going the full contract/concept route.
My biggest only issue with anytype, and generics in general, is that the lack of interfaces/protocols/concepts gives you hard to read error messages similar to C++ templating errors (albeit much nicer than those) where the error is now where the type is used in the function instead at the call site where the function is used. The current state is ok, but very annoying at times.
Yes it’s definitely better error messages, then the 500 lines of template instantiation bloat, but it really takes some getting used to the error messages and the patterns, and that is enough evidence that it’s a case of a local maximum. Especially considering that this is one of the only spot where it’s really easy to write and hard to read.
hm, anytype is THE reason I’m doing Zig! comptime duck-typing is IMHO one of the greatest features.
The concept is fantastic no questions asked, the implementation feels sub-optimal, as a user I can’t say if this is a necessary evil and this is in fact the best balance of power/expressiveness and low compiler complexity. Or if it can be improved. I love duck typing it’s a really great features, that really brings Zig together. but just the anytype keyword, and it’s semantic goes IMHO against some of the principle of the language, and it makes it more confusing than it should be.
Duck typing is great! The problem is that Zig’s type system is primarily nominal, which means that you’re not able to tell the type system which kind of duck you want it to be. Adding support for structural subtyping feels like a natural extension of anytype to me.
I found out that you can often restructure your code/api in a way that it doesn’t matter what the “duck-subtype” x is. I know what you mean but I don’t agree with the outcome.
BTW: whole IDEs were built with duck-typing and I think a lot of then-invented patterns are still relevant with Zig’s anytype (not always a good idea but relevant)