4 ms·

> "Proper generics" is a red herring put forth by Pike, where its would only be OK to have generics if it came without any tradeoff at all, where tradeoffs even

> "Proper generics" is a red herring put forth by Pike, where its would only be OK to have generics if it came without any tradeoff at all, where tradeoffs even include the compiler being harder to write. This. To further add to this, an argument against generics used to be worries about showing compile times, but that didn't stop rewriting the compiler in Go or implementing SSA. Go's compile times are still much slower than they were. Point being that generics aren't seen as important, not as being too difficult to implement correctly.

remus 10y ago
> ... but that didn't stop rewriting the compiler in Go or implementing SSA. Go's compile times are still much slower than they were. I think the trade offs in those cases were pretty clear. The switch from c to go was made so that compiler development would be easier, and indeed you could well argue that it was a big enabler in work like reducing GC pause times. Similarly, one of the big reasons for switching to the SSA back end was to enable improved optimisations down the line. I think the results of this work are fairly clear already: in 1.7 binaries are generally smaller than 1.6, sometimes by as much as 20-30%. I think the trade-offs for generics are less clear. Compile times may increase, they'd add complexity to any implementation and, perhaps most importantly, they'd add significant complexity to the language. On the other hand, they make certain classes of problem substantially easier and significantly simplify some APIs.