4 ms·

I think the main fear people have isn't the concept of generics, but the implementation of generics. Go's primary goal is simplicity, and implementing generics

• bmon 8y ago
  If language features were free we'd likely have had generics for a long time now. Unfortunately generics is a trade-off: you get development speed/ease and pay for it in compile time, binary size and/or execution speed. This seems to be slowly changing, but Go was designed to be a solution to Google problems - python being slow but some c++ applications taking literal hours to compile. Keeping that perspective in mind makes it easier to understand why Go maintainers have not accepted an implementation of generics into the language yet.
  • atilaneves 8y ago
    If you maintain type safety, you'll pay in increased compile times with or without generics. You'll either hand-roll an implementation for each type (https://golang.org/pkg/sort/ https://golang.org/pkg/sort/) or you'll generate code before actually compiling. The problem doesn't go away.
• ryeguy 8y ago
  But like I said, Go doesn't have an answer for generics. So the complexity just lives in userland code instead of the language itself. The problem and complexity doesn't go away.
  • stcredzero 8y ago
    If the choice is between badly implemented generics, and having the problem manifested as userland code, I'll take the latter. I've actually had to debug C++ production code produced by the confluence of templates that had no source code of it's own. At least with boilerplate, you can simply see what's going on right there.