This reminds me of creator of „brew” who got declined by Google because he couldnt write a reverse binary tree search in 1h.
Dont mind that half of Google is using his work for free.
Dont mind that half of Google is using his work for free.
Also, nobody at google is using homebrew for work.
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.
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.
But, as usual for internet discussions, it is fun to rathole on side conversations.
No one’s running Xcode on the web or on a Linux 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.
I'll admit that surprises me greatly, I can't see why it's considered more efficient, but hey, Google.
A poor little laptop would break down and cry.
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.
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.
You probably shouldn't be using dpkg or rpm for that, either, unless your CI and deployment targets are running the exact same version of Linux that you are, and even then—there are usually cleaner and more cross-platform/distro ways to do it, especially if you need to easily be able to build or run older versions of your own software (say, for debugging, for git-bisecting, whatever). I continue to wonder how TF people have been using typical Linux package managers, that they end up footgunning themselves with brew. "Incorrectly", I suspect is the answer, more often than not.
Where it excels is installing the tools that you use, that aren't dependencies of projects, but things you use to do your work.
Get your hammer from Brew. Get your lumber from... uh, the proverbial lumber yard, I suppose. Docker, environment-isolated language-specific package managers, vendored-in libs, that kind of thing.
I don't install project deps with Brew (it's a bad idea, but, again, so is doing that with dpkg or rpm or whatever directly on your local OS, a lot of the time) but I do install: wget, emacs, vscode, any non-Safari browsers I want, various xvm-type programs (nvm, pyenv, that stuff), spectacle, macdown, Slack, irssi, and so on.