You are factually wrong. Not only that, you're conflating several different processes and team rules.

Many googlers use brew to install applications on their laptops. This not against policy. Other googlers work with code stored directly on their laptop. There may even be developers who are obtaining deps (for their own builds) from brew.

The problem with the brew author is that he had every opportunity to make himself look hirable at Google but instead chose to write an incorrect screed and publish it on the internet.

You need a full Santa exemption with business reason to use brew. The average person working on some server that deploys to borg does indeed use their Macbook as a thin client. Who's obtaining deps for their builds from brew? If you're building stuff on Mac, it's via bazel and all your deps are in source control.

I never said anybody is obtaining deps for builds- that's all UncleMeat.

At the time I used brew (5 years ago) it didn't require a santa exception with business justfication (and my justification would have been "I need this for my work"). Fortunately this wasn't really a problem for me any way as I don't even look at Mac machines as anything other than a thin client.

It is true that this was the problem with the brew author. Homebrew being part of the typical Google workflow is entirely independent of the situation.

But, as usual for internet discussions, it is fun to rathole on side conversations.

The best part is, I was defending the use of homebrew (which I absolutely hate) and local development (which is far inferior, IMHO, to blaze/forge/citc/piper). I had really hoped releasing abseil/bazel would help but sadly, it was done too little, too late.

How are those tools better than for example plain old mvn or gradle ?

That seems unlikely, given that they’ve implemented an Xcode project generator for iOS apps built with their build system: https://tulsi.bazel.build/

No one’s running Xcode on the web or on a Linux machine.

I’m sure there are a few open source developers who use brew or Xcode directly, but most Mac builds happen in a distributed build system wired up to use remote macs. Yes, via Xcode. Not on local machines.

The mac build system is wild. It is still all done remotely with a farm of macs running xcode. You still don't build code for running on macs on your local machine.

You actually do, what Tulsi generates is an XCode project that has shell script build steps that call out to bazel. Bazel underneath the covers will end up calling the clang that comes with XCode.

Do you work for Google? I'm just doubting you a little. Like the guy from project zero is finding bugs in Windows via ssh to a Linux machine? Definitely going with Doubt here.

There are a few outliers, but yeah. Per policy, no code is allowed on laptops. And because Google's build tooling is very centralized basically everybody works on the same kind of machine.

The folks developing Chrome for Windows or iOS apps might have different workflows, but even then they aren't going to be using brew because of Google's third party code policies.

They are correct. Stuff like project zero is an extreme outlier. I've been using a MBP for 5 years and have never used homebrew on it.

Cheers for clarifying :)

I'll admit that surprises me greatly, I can't see why it's considered more efficient, but hey, Google.

The first program you build in Noogler training takes more compute and io to build than the Linux kernel. The distributed build systems laughs at such a trivial program and barely breaks a sweat at programs 10x that size.

A poor little laptop would break down and cry.

Google has a giant monorepo. It is too big for git. (Virtually) everything is built from source. Building a binary that just runs InitGoogle() is going to crush a laptop.

I believe that there are also a bunch of IP reasons for this policy, but from a practical perspective doing everything with citc and blaze is really the only option.

Can you share the order of magnitude we're talking about here?

probably efficient because their codebase size would outstretch local disk space requirements, and also would allow for comprehensive access controls

...worked in another place which didn't allow local code. It was the most horrible dev experience I had. Cannot fathom why google went that way too.

Google lives and does by its distributed build system. Most devs don’t even have exactly have code on their local workstation either—it comes via remotely mounting a file system.

But 99.9% of the builds happen remotely. So local vs remote code just isn’t that relevant.

It is also true that Google spends millions and millions on its dev environment every year, so this isn’t your average “no code on laptops” situation.

Is the code being in a VM mutually exclusive with having homebrew installed?

Why would I install homebrew on a work laptop if I cannot build or run code on my work laptop? Why would I install a dependency management system if company policy is that all third party code is checked into the repo as source and built using blaze?

Because you can also install applications via homebrew. I use it for a few things, including installing bat, delta and other Rust coreutil replacements that I prefer. I absolutely do not use homebrew for project dependencies.

When I worked for google, several of my projects were developed locally on laptops. My intern (who was developing tensorflow robotics computer vision stuff) used homebrew to install tools. Not everybody at Google used blaze.