4 ms·

I've seen a few people say 'google3'. Q: is it actually the code that you loved, or simply the tooling that exists? (and if it's tooling, why can't that type

I've seen a few people say 'google3'. Q: is it actually the code that you loved, or simply the tooling that exists? (and if it's tooling, why can't that type of tooling be replicated for other codebases outside of google?)

okdood64 2y ago
> (and if it's tooling, why can't that type of tooling be replicated for other codebases outside of google?) The elegance of the tooling from what I hear is that there's tons of different tools maintained by different teams that work seamlessly (and fast) together to produce google3 and all of its supporting pieces. But to answer your question, sure it can. But good luck building your own. Google has been doing this since the 2000s. And if you're a big company already, you've already bought into your existing patterns & design choices; things like that are VERY hard to change.
aleksiy123 2y ago
Its both. The tooling has a very direct impact on the quality of the code. I think the reason its not easy replicable is: 1. It takes a ton of initial investment and ongoing maintenance but its worth it when your code base is gigantic. 2. There is a consistent set of top down enforced rules. With the consistency it becomes much, much easier to build tight integrations between tools. (almost?) everything is buildable by a single build system (blaze). When anyone can consistently build/test/run anything in your codebase it becomes a lot easier to build a whole host of potential tools like code search. Probably someone can dive deeper than I can. But one thing I learned the most important property for a code base to be maintainable/scalable is consistency.
- aleksiy123 2y ago
  One more thought, is also how much other systems can utilize the same tooling/workflows by just storing things in source code. Things that would probably traditionally stored as application state in a database are often stored instead in google3 as config. Things like on team rosters, on call rosters, code review permissions, service permissions, feature flags. All of it stored in google3 and can all utilize the same consistent set of tooling like presubmit test, integration tests, deployment automation, permissions, code search. Its sort of like Infrastructure as Code but more.
  - kridsdale3 2y ago
    I also love the built-in history diffing that this gives you on those files.
  - nurple 2y ago
    Org as code
- ryukafalz 2y ago
  > When anyone can consistently build/test/run anything in your codebase it becomes a lot easier to build a whole host of potential tools like code search. As someone who hasn't worked for Google, how does Google's implementation of this differ from e.g. Guix/nixpkgs? Being able to easily build/test any available package is a big reason I like using tools like those.
  - aleksiy123 2y ago
    I'm unfortunately not that familiar with the internals. I think the public bazel (public version of blaze) docs is probably the best place to look. https://bazel.build/basics/hermeticity https://bazel.build/basics/hermeticity
fragmede 2y ago
That type of tooling can be replicated. That's why every Xoogler tries so hard to get Bazel adopted on everything they touch. Sometimes that's appropriate, sometimes it's not, but that's why. Bazel isn't the whole of everything though, the other piece being exported is kubernetes, which isn't Google's borg, but that's its roots. There's Apache Airflow if you need a workflow engine like Sisyphus, no shortage of databases to choose from, though now we're drifting into the operations side of things. But basically, Google has invested untold millions of dollars in the form of SWE and other engineering hours into making Google3 operate. If anyone else invested that kind of dough, with enough smarts, they'd also be able to make it a good experience. The problem is few people have that kind of budget, and even fewer invest in that thing, preferring to use free tools instead. What tool do you use to edit code, and how much did your employer spend on that for you?
- tiffanyh 2y ago
  So the development experience Github is marching towards doesn't compare? E.g., Codespaces, CoPilot, Actions, etc? (genuinely curious, not trolling)
  - fragmede 2y ago
    It does! Working like Google is like that but having had decades to build that dream, using the resources that only a megacorp could bring to bear in the problem, and in a monorepo. The fact that it's a monorepo is not to be dismissed. git doesn't work for monorepos. Codespaces is like CitC; I haven't been a Google since the rise of AI so I can't comment on how the internal equivalent to Copilot is; Actions is very primitive compared to what Google has, but yeah, you can see where it's going. it doesn't compare right now but it could, eventually.
    - kridsdale3 2y ago
      The Gemini-powered copilot is fine, but has so far, for me, only done automated like "heres a simple method based on the comment you wrote", or "I patched in a change to the other callsites when you renamed this thing". I have also not used it in 2 months so it's probably better already. I still mainly do my LLM assisted coding in chat-style interfaces that are more like pair programming by mail. I think the Gemini code assist is coming out as a consumer product, I forgot the name, because Google is awful at branding.

okdood64 2y ago

> (and if it's tooling, why can't that type of tooling be replicated for other codebases outside of google?) The elegance of the tooling from what I hear is that there's tons of different tools maintained by different teams that work seamlessly (and fast) together to produce google3 and all of its supporting pieces. But to answer your question, sure it can. But good luck building your own. Google has been doing this since the 2000s. And if you're a big company already, you've already bought into your existing patterns & design choices; things like that are VERY hard to change.

aleksiy123 2y ago

Its both. The tooling has a very direct impact on the quality of the code. I think the reason its not easy replicable is: 1. It takes a ton of initial investment and ongoing maintenance but its worth it when your code base is gigantic. 2. There is a consistent set of top down enforced rules. With the consistency it becomes much, much easier to build tight integrations between tools. (almost?) everything is buildable by a single build system (blaze). When anyone can consistently build/test/run anything in your codebase it becomes a lot easier to build a whole host of potential tools like code search. Probably someone can dive deeper than I can. But one thing I learned the most important property for a code base to be maintainable/scalable is consistency.

aleksiy123 2y ago
One more thought, is also how much other systems can utilize the same tooling/workflows by just storing things in source code. Things that would probably traditionally stored as application state in a database are often stored instead in google3 as config. Things like on team rosters, on call rosters, code review permissions, service permissions, feature flags. All of it stored in google3 and can all utilize the same consistent set of tooling like presubmit test, integration tests, deployment automation, permissions, code search. Its sort of like Infrastructure as Code but more.
- kridsdale3 2y ago
  I also love the built-in history diffing that this gives you on those files.
- nurple 2y ago
  Org as code
ryukafalz 2y ago
> When anyone can consistently build/test/run anything in your codebase it becomes a lot easier to build a whole host of potential tools like code search. As someone who hasn't worked for Google, how does Google's implementation of this differ from e.g. Guix/nixpkgs? Being able to easily build/test any available package is a big reason I like using tools like those.
- aleksiy123 2y ago
  I'm unfortunately not that familiar with the internals. I think the public bazel (public version of blaze) docs is probably the best place to look. https://bazel.build/basics/hermeticity https://bazel.build/basics/hermeticity

fragmede 2y ago

That type of tooling can be replicated. That's why every Xoogler tries so hard to get Bazel adopted on everything they touch. Sometimes that's appropriate, sometimes it's not, but that's why. Bazel isn't the whole of everything though, the other piece being exported is kubernetes, which isn't Google's borg, but that's its roots. There's Apache Airflow if you need a workflow engine like Sisyphus, no shortage of databases to choose from, though now we're drifting into the operations side of things. But basically, Google has invested untold millions of dollars in the form of SWE and other engineering hours into making Google3 operate. If anyone else invested that kind of dough, with enough smarts, they'd also be able to make it a good experience. The problem is few people have that kind of budget, and even fewer invest in that thing, preferring to use free tools instead. What tool do you use to edit code, and how much did your employer spend on that for you?

tiffanyh 2y ago
So the development experience Github is marching towards doesn't compare? E.g., Codespaces, CoPilot, Actions, etc? (genuinely curious, not trolling)
- fragmede 2y ago
  It does! Working like Google is like that but having had decades to build that dream, using the resources that only a megacorp could bring to bear in the problem, and in a monorepo. The fact that it's a monorepo is not to be dismissed. git doesn't work for monorepos. Codespaces is like CitC; I haven't been a Google since the rise of AI so I can't comment on how the internal equivalent to Copilot is; Actions is very primitive compared to what Google has, but yeah, you can see where it's going. it doesn't compare right now but it could, eventually.
  - kridsdale3 2y ago
    The Gemini-powered copilot is fine, but has so far, for me, only done automated like "heres a simple method based on the comment you wrote", or "I patched in a change to the other callsites when you renamed this thing". I have also not used it in 2 months so it's probably better already. I still mainly do my LLM assisted coding in chat-style interfaces that are more like pair programming by mail. I think the Gemini code assist is coming out as a consumer product, I forgot the name, because Google is awful at branding.