> But I prefer Rust over Zig. The main difference is Rust chooses a "closed world" model while Zig chooses an "open world" model: in Rust, you must explicitly implement a trait while in Zig as long as the shape fits, or the `.` on a structure member exists (for whichever type you pass in), it will work (I don't use Zig so pardon hand wavy description).

Do you happen to have a more specific example by any chance? I’d be interested in what this looks like in practice, because what you described sounds a bit like Go interfaces and from my understanding of Zig, there’s no direct equivalent to it, other than variations of fieldParentPtr.

▲

lukaslalinsky 2 hours ago | parent [-]

They are referring to `anytype`, which is a comptime construct telling the compiler that the parameter can be of any type and as long as the code compiles with the given value, it's good.

It's an extremely useful thing, but unconstrained, it's essentially duck typing during compile time. People has been wanting some kind of trait/interface support to constrain it, but it's unlikely to happen.

	▲	OskarS 22 minutes ago \| parent [-]
		Conceptually it's quite similar to how C++ templates work (not including C++20 concepts, which is the kind of constraining you're talking about). I quite like it when writing C++ code. Makes it dead easy to write code like `min` that works for any type in a generic way. It is, however, arguably the main culprit behind C++s terrible compiler-errors, because you'll have standard library functions which have like a stack of fifteen generic calls, and it fails really deeply on some obscure inner thing which has some kind of type requirement, and it's really hard to trace back what you actually did wrong. In my (quite limited) experience, Zig largely avoids this by having a MUCH simpler type system than C++, and the standard library written by a sane person. Zig seems "best of both worlds" in this regard.