5 ms·

I like generics as well, but this comment (and embedded links) made me appreciate why Go doesn't have them yet: https://news.ycombinator.com/item?id=9622417

I like generics as well, but this comment (and embedded links) made me appreciate why Go doesn't have them yet: https://news.ycombinator.com/item?id=9622417 I agree, the value in generics/templates is in not cutting and pasting an algorithm or container to handle multiple types safely. A true macro system (and Rust's is pretty good one to model after) also solves this problem, and I wonder if Go would ever consider adding such a thing. It seems like a safer approach.

qznc 10y ago
Did they consider the OCaml approach of "generic modules"? I would combine it with C++-style instantiation. By having it on the module level instead of functions/structs, you should be able to avoid the linker bloat. Are there OCaml users in the Go community? Also, there is the hybrid method between C++ and Java, which C# implements: Instantiation for value types and type erasure for reference types.
- civility 10y ago
  > Did they consider the OCaml approach of "generic modules"? Heh, I certainly can't speak for them, and I don't know what they've considered outside of that link. I also don't know C# or OCaml well enough to say if Go should/could adopt their strategies. However, Java's generics aren't very satisfying, and I think Go is wise to not jump in prematurely. Hygienic macros (as in Scheme or Rust (Nim? Elixir? Julia?)) seem like a more mature concept that could solve most of the problem.