I'm delighted to see that they're thinking about implementing generic methods, and even included the canonical Sort worst-case example.
The framing of the tradeoffs (slow programmer, slow compiler or slow execution) is interesting. To me it suggests that we'll go with "slow compiler", because slow programmer is always expensive, and slow execution is expensive when run at Google scale.
Although they did stick "and bloated binaries" alongside "slow compiler", which says maybe they haven't quite made their mind up.
They have been thinking about for a very very very long time now, i wonder how much longer since there are 2 release in a year and a lot is yet to be done.
I think the suggestion in the presentation was that it's a tradeoff: C++'s slowness at compilation is what enables it to be both fast at runtime and fast to program (at least when it comes to generic methods; it obviously has other time-sinkholes).
I agree though, I believe it should be possible to get good compilation speed with generic methods, leveraging the simplified syntax etc of Go.
I can't find a comprehensive overview of C++ compiler performance, but this article [1] seems to point towards #includes and duplicate template instantiation. Header file hell is specific to C/C++, but it'll be interesting to see how Go handles generics to tackle the latter issue (or y'know, if they decide not to because of this issue).
No, you don't have to pick between "slow programmers, slow compilers and bloated binaries, or slow execution". people have been telling them that since what ... 5 years?
The framing of the tradeoffs (slow programmer, slow compiler or slow execution) is interesting. To me it suggests that we'll go with "slow compiler", because slow programmer is always expensive, and slow execution is expensive when run at Google scale.
Although they did stick "and bloated binaries" alongside "slow compiler", which says maybe they haven't quite made their mind up.