4 ms·

I really dont like this. It just feels like people are trying to ram a square peg into a round hole. Personally I dont get why generics were needed in the first

I really dont like this. It just feels like people are trying to ram a square peg into a round hole. Personally I dont get why generics were needed in the first place. Every single example Ive seen so far, could be pretty easily replaced with `interface{}`. And now that we finally have generics, people still arent happy. Now that they have their round peg, they are trying to now ram it into a star shaped hole, as is being done in this post. I really wish people would just use the language as it is. Yes, it does cause for some repetition, but thats not the worst thing in the world. Compared to some Java codebases I have seen, Go is extremely simple already, in terms of "flatness" in the filesystem, and flatness in the type system. I think people should just know when to leave well enough alone. I dont think the complexity of generics is worth it for 99/100 use cases.

fsdjkflsjfsoij 5y ago
> Every single example Ive seen so far, could be pretty easily replaced with `interface{}` Of course they could just use interface{}... But by doing that they lose both type safety and performance.
- svnpenn 5y ago
  > they lose both type safety and performance I guess you think generics is a magic pixie dust that has the exact performance envelope as non-generic code?
  - fsdjkflsjfsoij 5y ago
    That depends entirely on the implementation. Almost every respectable implementation strategy is going to have better performance characteristics than an interface{} though.
  - sidlls 5y ago
    Not exact in all cases, but in some and very close in most others. And it isn't "magic pixie dust"--it is a lot of hard work to implement generics in a way that is both ergonomic for the programmer and efficient.
    - cle 5y ago
      I don't think OP was implying that it's not hard work, but that many folks act as if there are no perf tradeoffs with generics, when there are.
      - adambatkin 5y ago
        It depends. There is always an increased demand for memory (which can impact the whole hierarchy) but other than that it shouldn't be bad. And I think the point is that compared to interface{}, generics will almost always win. And realistically, compared to hand-rolled, you'd need to hand-roll (or codegen, whatever) multiple implementations which, as machine code, would end up exactly the same as the generic implementation. And what are we optimizing for anyway? Reading a bunch of code that uses an off-the-shelf library's Stack or Tree or whatever is always going to be easier to read than having to also have to inspect the three hand-rolled Tree implementations, two of which are probably buggy, in addition to the actual client code trying to use the tree to do real work. Or a library that implemented it using interface{} which is a big middle finger to the whole type system, completely discarding the compiler's ability to detect otherwise trivial mistakes.
jjtheblunt 5y ago
Aren't the language builtins (map[X]Y etc) themselves generic ?
- Groxx 5y ago
  And they're almost universally strongly preferred over custom collections, yeah. I very much doubt that's coincidence.

fsdjkflsjfsoij 5y ago

> Every single example Ive seen so far, could be pretty easily replaced with `interface{}` Of course they could just use interface{}... But by doing that they lose both type safety and performance.

svnpenn 5y ago
> they lose both type safety and performance I guess you think generics is a magic pixie dust that has the exact performance envelope as non-generic code?
- fsdjkflsjfsoij 5y ago
  That depends entirely on the implementation. Almost every respectable implementation strategy is going to have better performance characteristics than an interface{} though.
- sidlls 5y ago
  Not exact in all cases, but in some and very close in most others. And it isn't "magic pixie dust"--it is a lot of hard work to implement generics in a way that is both ergonomic for the programmer and efficient.
  - cle 5y ago
    I don't think OP was implying that it's not hard work, but that many folks act as if there are no perf tradeoffs with generics, when there are.
    - adambatkin 5y ago
      It depends. There is always an increased demand for memory (which can impact the whole hierarchy) but other than that it shouldn't be bad. And I think the point is that compared to interface{}, generics will almost always win. And realistically, compared to hand-rolled, you'd need to hand-roll (or codegen, whatever) multiple implementations which, as machine code, would end up exactly the same as the generic implementation. And what are we optimizing for anyway? Reading a bunch of code that uses an off-the-shelf library's Stack or Tree or whatever is always going to be easier to read than having to also have to inspect the three hand-rolled Tree implementations, two of which are probably buggy, in addition to the actual client code trying to use the tree to do real work. Or a library that implemented it using interface{} which is a big middle finger to the whole type system, completely discarding the compiler's ability to detect otherwise trivial mistakes.

jjtheblunt 5y ago

Aren't the language builtins (map[X]Y etc) themselves generic ?

Groxx 5y ago
And they're almost universally strongly preferred over custom collections, yeah. I very much doubt that's coincidence.