3 ms·

Before you dismiss compile time as "an overblown concern", I recommend reading Rob Pike's paper version of his talk, "Language Design in the Service of Software

by scott_s 12y ago

Before you dismiss compile time as "an overblown concern", I recommend reading Rob Pike's paper version of his talk, "Language Design in the Service of Software Engineering" (http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article). In particular, take a look at section 5, "Dependencies in C and C++." From that section: The construction of a single C++ binary at Google can open and read hundreds of individual header files tens of thousands of times. In 2007, build engineers at Google instrumented the compilation of a major Google binary. The file contained about two thousand files that, if simply concatenated together, totaled 4.2 megabytes. By the time the #includes had been expanded, over 8 gigabytes were being delivered to the input of the compiler, a blow-up of 2000 bytes for every C++ source byte. As another data point, in 2003 Google's build system was moved from a single Makefile to a per-directory design with better-managed, more explicit dependencies. A typical binary shrank about 40% in file size, just from having more accurate dependencies recorded. Even so, the properties of C++ (or C for that matter) make it impractical to verify those dependencies automatically, and today we still do not have an accurate understanding of the dependency requirements of large Google C++ binaries. The consequence of these uncontrolled dependencies and massive scale is that it is impractical to build Google server binaries on a single computer, so a large distributed compilation system was created. With this system, involving many machines, much caching, and much complexity (the build system is a large program in its own right), builds at Google are practical, if still cumbersome. I think that Pike makes a convincing case that fast compile times at scale are a reasonable requirement for their needs.

copsarebastards 12y ago
Compile times are an overblown concern, not because compile times don't matter, but because generics don't equate to long compile times. Two things: 1. Talking about C++ doesn't prove anything about the effects of generics on compilation time. C++ doesn't have generics, it has templates. Also, C++ is a particularly difficult language to compile quickly--it shouldn't be hard to compile a language faster than C++, even if you completely ignore templates/generics. If you want to make a reasonable comparison to Go's compilation, you should be looking at Java or C#. I've worked on an 800,000 line Java project and a 500,000 line C# project (the second made very heavy use of generics). The first took about two hours to build completely from scratch, the second, 40 minutes (both on not-particularly-powerful desktop workstations--the difference in time also is affected by the fact that there was 5 years between these projects). And like I said, typical builds of only changed code took <30 seconds. 2. I already said this, so I'll just quote myself: "If your builds are taking so long that server time becomes an issue, your code has built up too much cruft and it's time to refactor to reduce your size (failure to do this will cause much bigger problems than slow compilation)." 4.2 megabytes of code means that no one can reason effectively about the system, especially in a language as dense as C++.

by scott_s 12y ago

copsarebastards 12y ago

Compile times are an overblown concern, not because compile times don't matter, but because generics don't equate to long compile times. Two things: 1. Talking about C++ doesn't prove anything about the effects of generics on compilation time. C++ doesn't have generics, it has templates. Also, C++ is a particularly difficult language to compile quickly--it shouldn't be hard to compile a language faster than C++, even if you completely ignore templates/generics. If you want to make a reasonable comparison to Go's compilation, you should be looking at Java or C#. I've worked on an 800,000 line Java project and a 500,000 line C# project (the second made very heavy use of generics). The first took about two hours to build completely from scratch, the second, 40 minutes (both on not-particularly-powerful desktop workstations--the difference in time also is affected by the fact that there was 5 years between these projects). And like I said, typical builds of only changed code took <30 seconds. 2. I already said this, so I'll just quote myself: "If your builds are taking so long that server time becomes an issue, your code has built up too much cruft and it's time to refactor to reduce your size (failure to do this will cause much bigger problems than slow compilation)." 4.2 megabytes of code means that no one can reason effectively about the system, especially in a language as dense as C++.