Comment by frollogaston
9 hours ago
Part of me thinks Google's entire problem is crappy internal tooling, not really an anti-innovation environment. Just making a dev take 2x as long to get something done has a bigger effect than you'd think. With LLMs it's more like 10x now because even Gemini doesn't understand Google-internal tooling.
Google's internal tooling is still, hands down, better than anything that exists for the scale they operate at, and it's not even close.
Google's processes, however, is hands down the worst thing to exist for the scale they operate at, and it's not even close.
the processes are a result of repeated lawsuit
Google has close to the best internal tooling in the industry for a decade or so.
Then the Google engineers who joined Facebook missed it so much that they built a better replacement.
Replacement for what? Google has some good internal tools, mostly the older ones. They're lucky to be using React instead of Angular at Facebook though.
Angular was an acquisition and isn't all that commonly used within Google.
Closure was the homegrown framework that's everywhere. It is a different flavor of bad than Angular. Angular was basically "You too can make your Javascript look like HTML", Closure is "You too can make your Javascript look like Java", and nobody bothered to ask Why? For that matter, React was "You too can make your Javascript look like Ocaml." JQuery was the only framework that really let Javascript be Javascript (other than writing in vanilla JS, which post-ES2015 wasn't as insane as it sounds).
React? Lucky. I wrote Closure (with an S) at GOOG in anger 5 years ago, and only stopped because I switched teams.
Sounds like a big-company issue, large scale lead to large burden and complexity.
google had the best tooling a decade ago...
Okay yeah, fair point.
My comment was from a decade old perspective
Who has the best tooling now?
1 reply →
I have a friend at Google DeepMind who tells me that Google believes in AGI/superintelligence just as much as HN does, which is probably why no one with conviction wants to work there.
> I have a friend at Google DeepMind who tells me that Google believes in AGI/superintelligence just as much as HN does, which is probably why no one with conviction wants to work there.
With "believes in AGI/superintelligence just as much as HN does" do you mean that they are superbelievers or rather sceptical of AGI/superintelligence? I have seen both positions on HN.
Skeptical
Yes
How much belief is that? I tend to skip the HN posts that are about AI.
Most of HN does not take the idea of superintelligence seriously, and until this year did not take the idea of AGI seriously.
I think LessWrong is a much better community for rational takes on AI, they've been reasoning about these risks for years under a much more sound logical framework
15 replies →
A few months ago I heard Demis Hassabis say something, albeit vague, I doubt he truly believed regarding AGI. That AGI is relatively near is the party line everywhere. That may contribute to creating toxic environments and lousy investment decisions. So here we go with the FOMO.
I think HN believes in AGI. HN probably doesn't believe LLMs will lead to AGI.
Also lots of tech people, HN included, are waking up to technology not only including penicillin (net positive for humanity) but also dynamite (best case: net neutral).
Dynamite has been incredibly beneficial for humanity.
4 replies →
I believe in AGI to the extent that if what's going on between your ears isn't happening on a network of neurons, it's magic. And I also believe the idea that AGI is near is based on the emergent capabilities of LLMs. There's a chance that AGI will emerge from bigger faster better LLMs. But without a theory of when and how that will happen, I'm not counting on it.
It's not a tooling problem. It's more of a layer of policy problems. If you realize that you cannot run a simple experimental code even in non-production environment for weeks due to 10s of privacy, security, access, process and legal issues where you gotta collect a bunch of approvals, this is critical. And the problem gets worse because the tooling is too good when it enforces. There used to be some holes and circumvention which are all gone these days. This is probably why they said "the infra is good for services but not for research".
I don't even think it's good for services. It's not like you go through cumbersome reviews/tools and then things are safe. They have insane homemade config languages and obscure systems that 99% of SWEs don't really understand but won't say it out loud. That's how they dropped cns2, and the postmortem is never going to blame the tools.
Thank you!
Google’s tooling was, hands down, the worst I have ever encountered. I did 10 years at GOOG, 3 at AMZN, 4 in research, and another 5 at companies you have heard of but wouldn’t be impressed by, and every day GOOG infuriated me.
If the tools are all in the same monorepo idk if that's actually true
What do you mean about them being in the monorepo?
The tooling is not the problem. If shit takes forever to launch, it's because there are many stakeholders that need to be satisfied (some for security, some for regulatory, some for the kinds of politics you get in a company that employs almost half a million people.)
But GDM isn't gated on launches. They were freely releasing things internally for dogfood. Problem is that stuff was just not as good as the competition.
A particular Google product being shit is a data point, but is orthogonal to my opinion about why it is slow to launch products/features.
Maybe they are forced to use Google search.
No, they have an actually good internal search. And there are some good things like stubby, but again pretty annoying that Gemini doesn't understand stubby.
> because even Gemini doesn't understand Google-internal tooling.
this is false, it's very good at internal tooling.
Only the GFG models know anything internal. Regular Gemini isn't trained on any of that. And GFG is a much older base model, so people use the regular one. If the tools seem to handle google3 code ok, it's only because of skills and not the model itself, and then you run into issues with skill bloat. Sometimes the A/B test would give me the bad model of the day that'd try to grep all of piper.
Start in a blank directory and tell it to spin up a boq Scaffolding stubby server that responds with "hello world." Unless something has changed after I quit a few months ago, it won't know how to do that locally, let alone actually deploy it. Try the same outside Google with like a Flask server on AWS or GCP.
Your information is indeed out of date.
2 replies →
No longer the case
Uh isn’t google known to have the best tooling in the world
They earned that reputation in like 2005. Some people have been there so long (without doing side projects) that they don't know what non-Google tooling looks like in this decade or even previous.