I think there are multiple reasons why Zig is great fit for this:
- zig has powerful meta-programming, it's a bit like functional programming with structs. I would consider that high-level concept, at least comparable to traits and constraints
- zig has anytype duck-typing. in any function, you can say that some arg is anytype, and then you can pass anything to it. type-checking still works, because it's done when you actually instantiate the function with known type. this is great for flat and simple API surface.
- server-side code usually have short life-time (request), so you can just use arena for all allocations, and free everything when you finish, this is super-simple to do in zig, because every api accepts allocator if it needs to allocate. rust arenas have lifetimes, which makes them problematic to use/embed deep down in the hiearchy. zig is not aiming for 100% safety so this is easy.
> - zig has anytype duck-typing. in any function, you can say that some arg is anytype, and then you can pass anything to it. type-checking still works, because it's done when you actually instantiate the function with known type. this is great for flat and simple API surface.
Is this any different from generics? Rust lets you define arguments with `impl Trait` as a shorthand for a generic type `T: Trait`, but this sounds pretty similar to just defining a function over a generic type `T`, albeit with different syntax.
Yes, fundamentally. In Rust if you take a parameter of generic type T without any bounds, you cannot call anything on it except for things which are defined for all types. If you specify bounds, only things required by the bounds can be called (+ the ones for all types). Another difference is where you get an error when you try pass something which doesn't adhere to a certain trait. In Rust you will get an error at the call site, not at the place of use (except if you don't specify any bounds).
Zig is doing just fine without any trait mechanism and it simplifies the language a lot but it does come up from time to time. The usual solution is to just get type information via @typeInfo and error out if the type is something you're not expecting [0]. Not everybody is happy about it though [1] because, among other things, it makes it more difficult to discover what the required type actually is.
Ah okay, so this is like C++ templates then. This always feels a bit like halfway to duck typing to me; it'll still get caught at compile time, but I'll get errors at every single call site where I pass something wrong rather than just one in the definition, like you mentioned. I have the same gripes with Go's interfaces, although I think I'd prefer Zig's way of doing it because the experience would essentially be the same, just with less boilerplate.
Depends on the way generics is implemented in the language you're talking about.
In D, for example, Zig's `anytype` is equivalent to using a template type `T` in D without any constraints. The result is the same: the implementation can call any method, but it must exist when the type is instantiated (on an invocation).
same thing, done in a different way. the only notable difference (except of writing less code) is that zig does not type-check the code which you don't use, so the genericity goes a bit further than what you can do in rust.
- zig has powerful meta-programming, it's a bit like functional programming with structs. I would consider that high-level concept, at least comparable to traits and constraints
- zig has anytype duck-typing. in any function, you can say that some arg is anytype, and then you can pass anything to it. type-checking still works, because it's done when you actually instantiate the function with known type. this is great for flat and simple API surface.
- server-side code usually have short life-time (request), so you can just use arena for all allocations, and free everything when you finish, this is super-simple to do in zig, because every api accepts allocator if it needs to allocate. rust arenas have lifetimes, which makes them problematic to use/embed deep down in the hiearchy. zig is not aiming for 100% safety so this is easy.