4 ms·

Ease of deployment: the first and hardest deployment step is creating code worth deploying. Readability: I'm pretty sure having to create copies of container c

Ease of deployment: the first and hardest deployment step is creating code worth deploying. Readability: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less readable than generics, not more readable. Compile time: this is an overblown concern. If you're using a compilation system that compiles only the parts you change, your typical compilation should be so quick as to take negligible time. Complete rebuilds such as on a CI server should be happening asynchronously to development and therefore should only cost server time, which is of negligible value in comparison with development time. 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). Language simplicity: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less simple than generics, not more simple. Toolchain simplicity: I am not able rightly to apprehend the kind of confusion of ideas that could provoke someone to think this is relevant. Maintainability: I'm pretty sure having to create copies of container classes for each thing they can contain, or casting in and out of object, or wrapping all your contained classes in an interface, is less maintainable than generics, not more maintainable.

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++.

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++.