3 ms·
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
by 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 agoI 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 agoIt 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.