5 ms·

> 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

> 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.

> 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.