3 ms·

Googler, opinions are my own. I believe the YouTube video linked from the wired article goes into this, but there's more machine generated code checked in than

by kyrra 4y ago

Googler, opinions are my own. I believe the YouTube video linked from the wired article goes into this, but there's more machine generated code checked in than human generated code at this point. A lot of this is boilerplate or config data that is stored in source control. I feel like Google definitely believes that config is code, so we have a ton of configuration of our systems checked into Piper.

brundolf 4y ago
Why is the generated code checked in, vs generated as-needed later?
- onei 4y ago
  Pure speculation on my part, but I've noticed Go has generate and build as separate steps and it's standard to check in generated code. This split no doubt makes compilation a lot simpler/faster, but perhaps it's a reflection of standard practices the language authors were used to.
- azurezyq 4y ago
  Most of them are generated on the fly, like protos. But you know, there are tons of configs, all kinds of.
- danpalmer 4y ago
  Traceability, simplicity, all sorts of reasons. If you commit all your codegen’d stuff you don’t need to worry about how to run codegen in most places. You can enforce a lot of security properties, you can run large scale analysis on the code in production because it’s all “statically” available, etc. That said, I think Google’s source control ecosystem is really quite different to what’s publicly available with systems like Git/Hub/Lab etc, even to Phabricator. These approaches work well at Google but don’t necessarily translate to other tools in the same way. Don’t take these sorts of things as gospel, or even as google advice about good engineering. Understand what they achieve, and then figure out a way to achieve that same result with the tools available to you.
- exikyut 4y ago
  Theory: it makes secure builds that much more straightforward. You can just point goma at a repo and whatever it inhales is everything needed. The simplicity cascades downwards. For example, "everything comes from a repo" would make object (.o) caching that much more straightforward. And you can reason both about the logic behind a service and how it was configured from a single commit hash/CL.

by kyrra 4y ago

brundolf 4y ago

Why is the generated code checked in, vs generated as-needed later?

onei 4y ago
Pure speculation on my part, but I've noticed Go has generate and build as separate steps and it's standard to check in generated code. This split no doubt makes compilation a lot simpler/faster, but perhaps it's a reflection of standard practices the language authors were used to.
azurezyq 4y ago
Most of them are generated on the fly, like protos. But you know, there are tons of configs, all kinds of.
danpalmer 4y ago
Traceability, simplicity, all sorts of reasons. If you commit all your codegen’d stuff you don’t need to worry about how to run codegen in most places. You can enforce a lot of security properties, you can run large scale analysis on the code in production because it’s all “statically” available, etc. That said, I think Google’s source control ecosystem is really quite different to what’s publicly available with systems like Git/Hub/Lab etc, even to Phabricator. These approaches work well at Google but don’t necessarily translate to other tools in the same way. Don’t take these sorts of things as gospel, or even as google advice about good engineering. Understand what they achieve, and then figure out a way to achieve that same result with the tools available to you.
exikyut 4y ago
Theory: it makes secure builds that much more straightforward. You can just point goma at a repo and whatever it inhales is everything needed. The simplicity cascades downwards. For example, "everything comes from a repo" would make object (.o) caching that much more straightforward. And you can reason both about the logic behind a service and how it was configured from a single commit hash/CL.