

The Research Problems of Implementing Go - babawere
http://talks.golang.org/2014/research.slide#1

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

~~~
sehugg
It'd be hard to do worse in compilation speed than C++.

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

~~~
sehugg
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).

[1] [http://www.drdobbs.com/cpp/c-compilation-
speed/228701711](http://www.drdobbs.com/cpp/c-compilation-speed/228701711)

------
ye
I fucking hate this slideshows, they never work. Clicking around, scrolling,
nothing happens.

~~~
justinsb
The arrow keys don't work for you?

If it's got to be a slideshow, I much prefer this to SlideShare!

