Live data from Hacker News

A History of IDEs at Google

laurent.le-brun.eu

291–300 of 333 posts

Re: A History of IDEs at Google

#291
post #40

There's more history than this. Disclaimer: Xoogler (2010-2017). When I first started the environment you used depended entirely on language. In the C++ and Python space, there was the vim and emacs divide. With Java it was more complicated. Some still used vim/emacs but a lot of people used Eclipse. Now Eclipse was a real problem at Google because of the source control system. Java IDEs are primarily built to import…

Cider (and p4/g4c etc) was amazing when I left back in 2020, I loved it so much, and truly miss it. I rejoined Google last year, and they'd replaced it with a VSCode clone that truly was just a glorified text editor and most were all-in on mercurial as a piper/citc shim -- I was only there for 5 months before I decided not to stay, and I never managed to get Go type definition hints working.

p4 makes me wake up at night screaming.

Similar to that IBM/Rational ClearCase, both are so unfriendly compared to subversion/cvs or git/mercurial that I always struggle to believe why someone would torture themselves using that. Probably admins love them because they allow some tooling to be added.

Re: A History of IDEs at Google

#292
post #237

Earlier quoted context omitted.

Is that right? They use the version running in a browser?

Electron is literally the browser Chromium (the open source part of Chrome).

Yes, except Electron apps have the ability to break out of the sandbox because they control it. I take the point that the web stack is used in Electron apps, but it's the other issues, esp. as compounded by cross-browser compatibility that are hard to solve in what most people think of when you say "a browser" context.

Re: A History of IDEs at Google

#293

That most engineers use the same IDE at Google allows the company to collect a huge amount of telemetry about what features they are using, how often, and how much. Quite similar to the entire codebase being in a single repo, it allows a certain visibility into what is happening that just isn't possible other places. When Google wanted engineers to use AI features, it turned them on in Cider-V by default. And if you…

> When Google wanted engineers to use AI features, it turned them on in Cider-V by default. And if you turned them off, later updates would turn them back on.

How is that good? That would be the first thing that would force me to use IDE that is not controller by 1984 entities.

Re: A History of IDEs at Google

#294
post #287

Earlier quoted context omitted.

If GCP was its own company it would almost be a Fortune 50 company on its own. Youtube would be a Fortune 100 company. That seems a lot more successful than most software companies. Meta on the other hand, really just has ads.

Question is if it got there purely on the merits of the software? Marketing and general infrastructure build out were far more influential in their rise. Again, I am not meaning this as a knock on their strategy. It is valid and is producing real results. I just don't think their unified IDE is a meaningful contributor to it. The equivalent of boots on the ground is far more of a contributor there. I had similar comp…

Google has chosen to invest all across the stack in numerous ways. Why do they have 180k people working for them? Because they design their own racks, build their own machines, built their own network, designed their own databases, built their own scheduler, created their own build system, and yes invested in developer tools. I don't know what the coefficients are for each one, but you can go find plenty of older software companies that only try a handful of these and skimp on the rest.

I don't believe any of those companies have as many billion dollar successes as Google. They aren't the only company to do this, but they certainly do it at an unprecedented scale.

Re: A History of IDEs at Google

#295

When I left Google in the mid 2010s, there were a couple unusual constraints: 1. They had the majority of their code in a vast++ monorepo. 2. There was a policy that forbade having code from this monorepo on your laptop. Most companies and projects have orders of magnitude less code, and don't restrict where that code can be stored. It's interesting to learn about Cider and the other things Google built to address th…

I actually think these constraints _help_ the average project as well. By enforcing remote builds and execution you completely remove the need for something like docker. You also get cloud backups for your code automatically.

Re: A History of IDEs at Google

#296

Earlier quoted context omitted.

I was responsible for getting the investment and (and pushing on turndowns) in getting Google to one IDE, and also worked at IBM for a few years. I also spent lots of time talking with my counterparts in other places. So I know what others spend and were spendingin similar environments in terms of actual dollars, and where it roughly goes. So let me say - it was not a small investment, in part because the all-in cost…

Oh so it's YOUR fault. ;) Don't worry -- I came to love Cider for the simplicity. I tolerate Cider V, but its "anything" nature means it's not good at anything in particular. These days, I mostly use it to peek into what (Antigravity's internal equivalent) does. I was in the Eclipse camp, prior to the IntelliJ reversal. At the time there were at least double the number of active daily users of Eclipse, Google had hir…

> The decision was made to go with Eclipse. Then it magically went into some sort of internal box/decision process, and came out IntelliJ instead. I've always thought this was because of a sufficiently highly placed Android person with a personal preference, but I could be 100% wrong.

I'm relying purely on memory, but all of the reasons were super public at the time. The internal Java editor tooling team decided that they weren't investing any more time into Intellij. And then a few months later, the Android team relaunched Android Studio using Intellij with full internal support. The existing Java tooling squad put up some amount of fuss saying that they had already made the decision, and the Android team gave a long and diplomatic response that could be compressed down into, "we don't report to you and we don't care what you think." This coincided with the entirety of Google becoming mobile native, so the mobile team were given free rein to call the shots.

> IMO IntelliJ never worked very well in google3

YMMV, we had some people in Docs/Drive who invested a lot of time into making Intellij usable for everyone, and following their system, it worked way better for us than Eclipse did. All of the "Let me sing you the song of my people ::UI freezes::" memes were very true in my experience.

Re: A History of IDEs at Google

#297

Earlier quoted context omitted.

How is this so much faster than browsing my tiny little repo on Github? What is Github doing so wrong??

Wow that is a lot faster and nicer than Github. This is a good example of large companies wouldn't send someone across the street to pick up $1M off the ground. If Google actually released that and a repo to public, they could take Githubs throne. But a few $B business isn't worthit for them.

It's not that the $2B business isn't interesting, it's competing with GitHub would be a major undertaking and the opportunity cost of doing that is probably more than $2B.

Re: A History of IDEs at Google

#298
post #231

Earlier quoted context omitted.

Google has also been systematically destaffing various language infra teams. https://www.linkedin.com/pulse/google-fires-entire-python-te... https://www.airs.com/blog/archives/670 https://en.wikipedia.org/wiki/Google_Kythe etc

That is not quite the right word. For Python, the headcount was moved from the Bay Area (the most expensive place in the world to hire software engineers) to Munich (the most expensive place in Germany to hire SWEs.), for cost saving reasons.

The problem is most SWEs in Germany are not as good as most SWEs in the Bay Area. :(

Re: A History of IDEs at Google

#299
post #287

Earlier quoted context omitted.

Question is if it got there purely on the merits of the software? Marketing and general infrastructure build out were far more influential in their rise. Again, I am not meaning this as a knock on their strategy. It is valid and is producing real results. I just don't think their unified IDE is a meaningful contributor to it. The equivalent of boots on the ground is far more of a contributor there. I had similar comp…

Google has chosen to invest all across the stack in numerous ways. Why do they have 180k people working for them? Because they design their own racks, build their own machines, built their own network, designed their own databases, built their own scheduler, created their own build system, and yes invested in developer tools. I don't know what the coefficients are for each one, but you can go find plenty of older sof…

Are we disagreeing? My point, at large, is that they are able to spend more money on all things than most are. At the level that they spend, it will be easy to build a narrative that makes any particular spend look vital. It would also be easy to build a narrative to show any particular spend is a waste.

My contention would be that none of those narratives is a lie. But none would be that useful on their own, either.

Re: A History of IDEs at Google

#300
post #40

There's more history than this. Disclaimer: Xoogler (2010-2017). When I first started the environment you used depended entirely on language. In the C++ and Python space, there was the vim and emacs divide. With Java it was more complicated. Some still used vim/emacs but a lot of people used Eclipse. Now Eclipse was a real problem at Google because of the source control system. Java IDEs are primarily built to import…

One important piece of context that might make all these stories less confusing for non-googlers: Code references are less important inside Google editors, because we have a code viewer tool inside the web browser. Most people read, explore, follow references, and share permalinks to the view-only tool. It’s a lot better than viewing code in GitHub. It’s super fast, is connected to language servers and can actually t…

To be fair, code search still sucked for navigation comparing to IDE even in 2024. Even cider-v was rather so-so if you needed to navigate complex c++ code.

But I still remember days "edit in IDEA, debug in Eclipse"

Post reply on HN