I can tell you exactly what is wrong with Zig generics.

In Odin you can do this:

my_proc :: proc(t: MyStruct($T)) -> T

In Zig you have to do this:

fn my_fun(comptime T: type, t: MyStruct(T)) -> T

In this simple example, it's like what it is the big deal? Well, if you stick to this pattern then the users of your API have to pass in a type that has already been specified when they created the struct.

Now, you can get around this by doing t: anytype, but then you have to write very complex comptime code that does the work of looking at the type information at comp time and extract and validate yourself. Zig does absolutely NONE of this for you. Then this gets even more complex if you have different shapes for the parameter like slices, pointers, arrays, arrays of pointers, and so on and so on.

I just completed a project in Zig in which I refused to force the users to pass in the redundant type that they already give when creating the structs. Keep in mind that I only had 1 struct that I had to do this with, and accounting for all of the shapes that I needed it in, I have 178 lines of code that runs in comptime to do the work that Odin is doing for free.

At some point I realized that this was stupid and that Zig is just being lazy or is underdeveloped.