The Research Problems of Implementing Go(talks.golang.org)
talks.golang.org
The Research Problems of Implementing Go
http://talks.golang.org/2014/research.slide#1
2 comments
I'm still amazed that it's 2014 and they come up with such dishonest slides like: http://talks.golang.org/2014/research.slide#24
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?
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?
It'd be hard to do worse in compilation speed than C++.
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 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).
[1] http://www.drdobbs.com/cpp/c-compilation-speed/228701711
[1] http://www.drdobbs.com/cpp/c-compilation-speed/228701711
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.
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.