6 ms·

>The other key thing, according to Meckfessel, is that the system compiles code with unusual speed. In typical Google fashion, it spreads compilation tasks acro

>The other key thing, according to Meckfessel, is that the system compiles code with unusual speed. In typical Google fashion, it spreads compilation tasks across vast array of servers, rather than generating the executable software on the developer’s local workstation. I hope she has more than this to focus on as Go usage is picking up within Google. And with Go, just the local workstation can do it. :)

cromwellian 13y ago
That's only because the amount of Go code is small. Google builds all transitive dependencies from source in HEAD, so if there were 10 million lines of Go sitting in the repository, your local workstation won't cut it. It's not even the build times which are the most pressing issue these days, but the time for tests to run.
- nostrademons 13y ago
  One of the major design goals for Go was that incremental compiles should not require a rebuild of all dependencies. I believe they bake interface information into the library files for this reason. If you don't change a file, you shouldn't need to rebuild it. If you sync to a later CL, you might need to rebuild what's changed, but even then all this should be cacheable across the company. Go was designed as a language to avoid a lot of the mess that the build tools have to deal with for C++.
  - cromwellian 13y ago
    In theory the same applies to Java, if I have a java_library, and none of the inputs have changed, I shouldn't have to rebuild anything. But the theory often doesn't match up to the reality with respect to objfs caching of dependencies in my experience. Also, any non-trivial app at Google is going to touch non-Go dependencies.
sltkr 13y ago
I like Go, but I always thought that was a ridiculous selling point. Just look at your own comment: if Googlers are picking up Go, it must have been for other reasons than build speed, considering they have a compile farm at their disposal that can build millions of lines of C++ code (before or after preprocessing, I wonder?) in mere seconds. I have a suspicion that if you ask people who used Go why they chose that language over the many other available options, almost none will say "because the compiler is fast!"
- voidlogic 13y ago
  I agree. I was approaching from the angle of being amused that they obviously put a lot of work into making C++ compile reasonably fast when they created a language that, amongst other things, addresses that issue by addressing the actual causes of slowness (as opposed to some giant cluster). I agree that for very few people compilation speed is "their" winning Go feature. (Although it is handy for situations were you want to use Go like a scripting language using go run)
  - sltkr 13y ago
    I always thought of the Go team as mostly outsiders coming from Plan 9 who were being sponsored by Google, but otherwise aren't really an integral part of the company (but then again, I don't know much about Google's internal organization). > Although it is handy for situations were you want to use Go like a scripting language using go run `go run` isn't that fast, really. A simple "hello world" takes 320ms on my system, while the equivalent in C takes 40ms, and C++ takes 270ms. Honestly I can't of a single use case where I think Go's compiler speed matters. And again: that's coming from someone who likes Go for basically every other reason.
    - voidlogic 13y ago
      >I always thought of the Go team as mostly outsiders coming from Plan 9 who were being sponsored by Google, but otherwise aren't really an integral part of the company (but then again, I don't know much about Google's internal organization). Well Rob and Ken are from Bell/Plan 9, but Robert is from Java HotSpot. My understanding is they were allowed to take what was their "20%" side project and Go full-time once it showed promise for addressing Google's language problems. >`go run` isn't that fast, really. A simple "hello world" takes 320ms on my system, while the equivalent in C takes 40ms, and C++ takes 270ms. Shouldn't you be comparing Go to Python, Perl or PHP in the context of "go run"? Also, benchmarking "Hello World" programs is not usually a very meaningful activity in any context. > And again: that's coming from someone who likes Go for basically every other reason. I like Go too and I think we agree that the compile speed, while nice, is just gravy when it comes to what Go has to offer.

cromwellian 13y ago

That's only because the amount of Go code is small. Google builds all transitive dependencies from source in HEAD, so if there were 10 million lines of Go sitting in the repository, your local workstation won't cut it. It's not even the build times which are the most pressing issue these days, but the time for tests to run.

nostrademons 13y ago
One of the major design goals for Go was that incremental compiles should not require a rebuild of all dependencies. I believe they bake interface information into the library files for this reason. If you don't change a file, you shouldn't need to rebuild it. If you sync to a later CL, you might need to rebuild what's changed, but even then all this should be cacheable across the company. Go was designed as a language to avoid a lot of the mess that the build tools have to deal with for C++.
- cromwellian 13y ago
  In theory the same applies to Java, if I have a java_library, and none of the inputs have changed, I shouldn't have to rebuild anything. But the theory often doesn't match up to the reality with respect to objfs caching of dependencies in my experience. Also, any non-trivial app at Google is going to touch non-Go dependencies.

sltkr 13y ago

I like Go, but I always thought that was a ridiculous selling point. Just look at your own comment: if Googlers are picking up Go, it must have been for other reasons than build speed, considering they have a compile farm at their disposal that can build millions of lines of C++ code (before or after preprocessing, I wonder?) in mere seconds. I have a suspicion that if you ask people who used Go why they chose that language over the many other available options, almost none will say "because the compiler is fast!"

voidlogic 13y ago
I agree. I was approaching from the angle of being amused that they obviously put a lot of work into making C++ compile reasonably fast when they created a language that, amongst other things, addresses that issue by addressing the actual causes of slowness (as opposed to some giant cluster). I agree that for very few people compilation speed is "their" winning Go feature. (Although it is handy for situations were you want to use Go like a scripting language using go run)
- sltkr 13y ago
  I always thought of the Go team as mostly outsiders coming from Plan 9 who were being sponsored by Google, but otherwise aren't really an integral part of the company (but then again, I don't know much about Google's internal organization). > Although it is handy for situations were you want to use Go like a scripting language using go run `go run` isn't that fast, really. A simple "hello world" takes 320ms on my system, while the equivalent in C takes 40ms, and C++ takes 270ms. Honestly I can't of a single use case where I think Go's compiler speed matters. And again: that's coming from someone who likes Go for basically every other reason.
  - voidlogic 13y ago
    >I always thought of the Go team as mostly outsiders coming from Plan 9 who were being sponsored by Google, but otherwise aren't really an integral part of the company (but then again, I don't know much about Google's internal organization). Well Rob and Ken are from Bell/Plan 9, but Robert is from Java HotSpot. My understanding is they were allowed to take what was their "20%" side project and Go full-time once it showed promise for addressing Google's language problems. >`go run` isn't that fast, really. A simple "hello world" takes 320ms on my system, while the equivalent in C takes 40ms, and C++ takes 270ms. Shouldn't you be comparing Go to Python, Perl or PHP in the context of "go run"? Also, benchmarking "Hello World" programs is not usually a very meaningful activity in any context. > And again: that's coming from someone who likes Go for basically every other reason. I like Go too and I think we agree that the compile speed, while nice, is just gravy when it comes to what Go has to offer.