Also can add compilation time as an upside to vtables.

And using vtable in code feels cleaner compared to using generics

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.

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.

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.