3 ms·
> it's also a really complex one! No, it's a very simple one, so much so that it's erasable: https://news.ycombinator.com/item?id=24293611 https://news.ycombi
by pron 6y ago
> it's also a really complex one!
No, it's a very simple one, so much so that it's erasable: https://news.ycombinator.com/item?id=24293611 https://news.ycombinator.com/item?id=24293611 And still it is probably the most complex aspect of Zig.
> Zig is cool, but I hoped the “generics are too complex of a feature” meme would die now that Go is getting generics, and I'd be really sad to see come back…
You've misunderstood me. Generics are a good thing -- if that's all you have. But if you have generics and procedural macros, it turns out that you can do the work of both with a feature that's simpler than either. The capability generics add is a very important one, but given that low-level languages need another one as well, it turns out that generics can be subsumed into that one without being a separate and additional construct. Zig has generic types and concepts/typeclasses; these just aren't atomic language constructs.
- littlestymaar 6y ago> But if you have generics and procedural macros, it turns out that you can do the work of both with a feature that's simpler than either. Here I think we just have a different subjective perception of what simplicity is. I much prefer have two orthogonal systems which do their own business than having a single more powerful tool than do both (like having slices + references instead of the all powerful pointer) Anecdotal note: more than 10 years ago, the Go team pitched why they didn't need generics nor macros, because code generation would solve both problems (+ others), and now they're on their way back to add generics to Go (with a lot of hassle).
- pron 6y ago> I much prefer have two orthogonal systems which do their own business than having a single more powerful tool than do both (like having slices + references instead of the all powerful pointer) OK, but that's not quite the situation. Here we're talking about languages that have, or will have, the single "more powerful" construct, and also the more specific, special case one, as two separate constructs, even though one of them would have sufficed. Again, Zig has parameterized types, and very elegant and powerful ones -- they're functions that take some types as argument and return a type. It just doesn't have generics as a separate construct. Rather, it is a special case of a more general one (that Rust and C++ will also have).
- int_19h 6y agoZig comptime functions that take and return structs consisting partially (or wholly!) of types reminds me of OCaml functors, and should perhaps be compared to them rather than generics.