Would it truly kill Zig to add native interface support ? All that ceremony is quite heavy and also somewhat error prone.
If nothing else, maybe they can add some helpers in the standard lib or codegen in the standard tooling to make stuff like this easier ? So one need not manually code all the function pointer types for methods and the dispatch in the interface type .
Yes, Zig is meant to be a low-level programming language, but stuff like this is basic table stakes nowadays. People will just make custom code generators after Zig 1.0 to do this exact thing - and they will likely be dozens of such custom code generators with subtle differences.
There's just one feature Zig lacks, which would have allowed for full automation of interface definitions. In Zig you can programmatically construct data types with compile-time programming, but such types aren't allowed to have methods: https://github.com/ziglang/zig/issues/6709
This is an intentional limitation, because the language creator worries the feature would be abused.
I strongly dislike "this feature could be abused, so we won't add it" as reasoning for language design decisions. It just doesn't sit right with me. I think designing to avoid "misuse" (i.e. accidentally shooting yourself in the foot) is great, but avoiding "abuse" just reads as imposing your taste onto all users of your language. I don't like this, so nobody should be able to do it.
But oh well, if you're using Zig (or any other language using auteur-driven development like Odin or Jai or C3) you've already signed up for only getting the features that the benevolent dictator thinks are useful. You take the good (tightly designed with no feature bloat) and the bad ("I consider this decision unlikely to be reversed").
Pascal was like this. Turbo Pascal was just a plain vanilla Pascal which was deemed sufficient. But when Borland themselves wanted to make a GUI, suddenly there were many language extensions added and Delphi was born. Until then the users weren't taken seriously.
> avoiding "abuse" just reads as imposing your taste onto all users of your language.
I believe languages are all about bias. A language must represent the preference of the community using it.
We should all learn from the case of Lisp, which is the simplest language and likely the most expressible language. The community suffered from the serious fragmentation driven by the sheer simplicity of the language and tons of NIH syndrome. It took them 30 years to get a standard CL, and another 20 years to get a de facto standard package repository (QuickLisp).
Even Ada, Modula-2, Object Pascal eventually got them.
Zig is trying to fix C, by delivering stuff already present in Modula-2, minus comptime, in a C like clothing.
The judge is still out there if it will become something unavoidable in some industry circles, or just yet another programming language to talk about.
From my point of view, being stuck in the past of systems languages design, during the AI age where the actual language becomes slowly irrelevant, it will mean the latter.
I think you have fallen into an AI hype trap. Language choices still matter.
For the time being.
It was not a trap being an early Fortran adopter and envisioning what a couple of decades later would be the future of Assembly programmers.
I already do lots of programming where the underlying language hardly matters.
I think it will turn out that even for AI some language will be much more easily to code systems in than others. We maybe even get languages optimized for this in due time. So I'm not at all on board with languages becoming irrelevant with AI age. I can even see it happening that extreme typing like lean will be best. Sure it will probably take more compute to design a system using it, but that may be offset by the additional mistakes it prevents. No company likes to code in lean, since you require highly skilled people and it takes ages. But AI can defeat both of those while still getting the advantages.
Agreed that native interface support is table stakes for any language now. It would avoid so much boilerplate - nevermind the time wasted examining the code to see what kind of ad-hoc interface any given piece of code is using - and how to retrieve the ridiculous zig vtable data member for each pseudo class instance. It just amounts to useless noise in the code, rather than succinctly stating the intent.
> nevermind the time wasted examining the code to see what kind of ad-hoc interface any given piece of code is using
this is not really a problem I've encountered. did you have a specific case where you got puzzled?
In every different zig project you have to read the source code to see how their specific ad-hoc interface scheme works. Case in point - this article uses a method `pub fn implBy(impl_obj: anytype)` to connect instances to a vtable. The new zig writer uses a `.interface` data member scheme: https://www.openmymind.net/Zigs-New-Writer/ in addition to understanding when and when not to use it.
I wonder if it's possible to not lock themselves into an ABI with a built in vtable implementation? I kinda get where they're coming from: let vtables be a user problem; but, yeah, modern compilers can do magic when they "know" the rules for built in vtables. It kinda feels like they're leaving a real performance opportunity on the ground?
I don’t find the lack of built-in interface in Zig to be a big problem. Yes. It has some boilerplates to roll in by hand, but all of the work are confined in the interface and only required to be done once.
The benefits of the language outweigh the minor inconvenience.
>Yes, Zig is meant to be a low-level programming language, but stuff like this is basic table stakes nowadays.
I think it is table stakes for higher level programming language. Zig wants to be somewhat like high level assembly.
There is still someway to go before 1.0 so may be something will be done. I mean I am still uneasy with them focusing so much on async.
Agreed, this puts me off using Zig. I can’t endure this level of boilerplate any longer.
More than lack of features, what puts me off is the whole anti-intellectualism in language design from these communities, than kind of sprung of Go designers.
So while as language geek, I will spend the time to understand and play with them long enough to be able to know what I am actually talking about, using said languages for project delivery only if it is a customer requirement of some sort.
> somewhat error prone
do you have any evidence for this? what is the error you're proposing here?
I meant human error - easy to mess up when coding this boilerplate, esp if there are more number of methods. Sure some 'perfect' programmers will always get this right but the vast number of us regulars will not. Also, it is not straightforward to discover these interface types in a code base.
I like Zig and eagerly await 1.0, just wish it was not quite so bare-bones.
well if you mess up most basic things won't the compiler catch you? i was wondering what sorts of logical errors you were expecting.
No, I don't think the compiler will catch all errors. Wrong type specified in adapter, for example (typical copy-paste mistake). Signature mismatches between anyopaque and MyType, forgetting to assign a function in the v-table, etc
i think at least forgetting to assign a function is not possible? the compiler will catch that.
This is like the inverse of the normal C++ vtable. Normally the whole point of having a separate vtable (as opposed to just a bunch of function pointers directly in the struct) is so that you can share a single one between all instances, at the cost of one extra indirection. But here a copy of the vtable is instead attached to one individual instance, and yet it still does this one extra indirection to get to the implementation object.
Yes. You're right. It's not the typical C++ vtable.
I wrote a second blog for the C++ style vtable. https://williamw520.github.io/2025/07/17/memory-efficient-zi...
The first version is faster (one pointer indirection) with more memory consumed. The second version is more memory efficient sharing a single vtable for all instances, a bit slower (two pointer indirections).
The extra indirection is a reasonable tradeoff in Zig because it enables heterogeneous collections of implementations while maintaining type safety without requiring inheritance.
Isn't it a common refrain that a language one hasn't used much would be perfect if only had this one feature my favourite language has
Why is Zig so inconsistent in its syntax?
We see:
pub fn implBy
(impl_obj: anytype)
v_setLevel
anyopaque
Function name in camel case. Variable and parameter in snake case.
You've put the
pub fn implBy(impl_obj: anytype) Logger
Function in a weird place. Normal practice is for the specific implementations to have a getLogger function to create the logger. For example, the allocators in Zig have you instantiate the top level and then call .allocator() on them to get the vtable + pointer to self.
It manages sanity a lot better, and the function implementations in the vtable can be private.
I did it this way so that the implementation doesn't need to know about the interface at all. The programmers can string the interface and implementation together with,
const intf = interface.implBy(implementation)
"The implementation doesn't need to know about the interface"
Lol sure. It "doesn't need to know" it just happens to magically have the correct functions as public methods to exactly map into your vtable constructor.
It's much easier to not do this. And have your implementations provide the vtable as a method.
If your implementation doesn't provide a method for this you need to wrap it with an object that does. Which you've done but you've decided that wrapper object should be the interface itself which is weird.
> Lol sure. It "doesn't need to know" it just happens to magically have the correct functions
This is called structural typing. Go and typescript have forms of it.
You get back an interface object at the end anyway. Why force the implementation to produce it? And if you have a type implementing 5 different interfaces, like one for Comparable, one for Iteratible, etc., do you want to stick 5 interface constructors in the implementation?
There's a false dichotomy in this whole discussion: for instance, a third option is having the interface as a separate declaration.
A simple example using traits (Rust):
// logger.rs
trait Logger {
fn log_something(&self);
}
// mycustomlogger.rs
struct MyCustomLogger;
// logger.rs or mycustomlogger.rs
impl Logger for MyCustomLogger {
fn log_something(&self) {
println!("Hello");
}
}
The difference is that there is no strong requirement on where exactly it needs to be [1].
This would likely require Zig to support "interfaces" at the language level, though.
--
[1] PS: there is the "orphan rule" for trait implementations, but I'm simplifying it here for the sake of the example
EDIT: formatting
> Do you want to stick 5 interface constructors in implementation
Yes. It's not as crazy as you might imagine, and it's more robust than the log delegator approach.
Also can add compilation time as an upside to vtables.
And using vtable in code feels cleaner compared to using generics
> That doesn’t mean polymorphism is off the table. In fact Zig has the tools to build interface-like behavior, making dynamic dispatch possible.
Do all code bases use the same pattern? Or does it not matter for interoperability, e.g. between an app and the libraries it consumes?
> Do all code bases use the same pattern?
Unfortunately no - it's a complete free for all - which is the problem. Conventions are great to a point but language enforced constructs are better.