Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A History of IDEs at Google

laurent.le-brun.eu

Post reply on HN
Print view View original

201–210 of 333 posts

Re: A History of IDEs at Google

#201

Post by IX-103 »

StilesCrisis wrote: post #5

"the advantages of having a single, extensible platform become even more obvious" -- imagine the impact that could be unlocked if we got the Android and Chromium workflows into CiderV/Critique! The article is framed around "all Googlers" but there is still a very large contingent of Googlers who cannot use these tools.

They're working on it. I think they even have a "beta" for Android/Chrome on CiderV. From what I heard it's slow and doesn't work with most of the existing tooling (want to reformat your source files? Too bad).

Re: A History of IDEs at Google

#202

Post by spwa4 »

hcnews wrote: post #163
randomCloud wrote: post #159

Earlier quoted context omitted.

I assume quick change became critique?

There was a code reviewer starting with M before Critique iirc (Mondrian I wanna say?). The M code reviewer was completely written in Python iirc.

No I mean that in code search you could click "edit" and just change something, which would then post a CL immediately, which you could set to auto-approve, for quick changes.

I believe it was part of cider (the first non-vscode version)

Re: A History of IDEs at Google

#203

Post by rossjudson »

taeric wrote: post #12

The advantages of a single platform are as obvious as the disadvantages. In that they are often whatever you want to frame them as for a narrative. I do think Google will continue to get results out of their tooling, as long as they are investing in the tooling. But that is not zero cost. Is it worth it for what they are doing? Largely seems to be. But it isn't like they are that much more successful at software proj…

The Acquired podcasts on Google are a solid background.

https://www.acquired.fm/episodes/google

Re: A History of IDEs at Google

#204

Post by rossjudson »

DannyBee wrote: post #99
w10-1 wrote: post #34

I had to laugh we he said it took a dozen people a couple years. That's a terribly small investment relative to the leverage over developer productivity, and pales in comparison to what eBay, IBM et al spent in similar large but specialized developer populations for integrated tooling. I'd like to hear the perspective of the developer/user; the IDE provider has some incentive to take credit and imply high utilization…

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 hired some original Eclipse devs who did an awesome job making Eclipse work at Google scale, and basically I was back to where I had been (in productivity) before joining Google.

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.

This made me sad. I escalated internally, compiled all of the usage numbers, did feature comparisons on what actually worked in each IDE, to no avail. Near the end, Eclipse's C++ support and refactoring actually worked reasonably well on Blobstore, which was NOT a small thing.

IMO IntelliJ never worked very well in google3, and certainly didn't have anywhere near the level of fluidity and speed that Eclipse had (all the way back from its VisualAge Smalltalk roots -- something even most users of Eclipse never really understood or got into). That said, Eclipse just had the wrong architecture for a massive monorepo. It could be made to work (and it was), but it was never a good fit...and getting the upstream changes needed was apparently problematic.

Plain simple Cider was better (in my mind) than IntelliJ's broken functionality that worked in the outside world, but not in google3 (at least not on the code bases that I worked in).

Plain old Cider just kept adding smart features that solved problems and made it nicer. By the time Cider V was coming, it had big shoes to fill.

Re: A History of IDEs at Google

#205

Post by kccqzy »

tipsytoad wrote: post #150
kccqzy wrote: post #141

Earlier quoted context omitted.

When I was there all the cool people used mercurial. Git5 was creaky and didn’t work well but hg worked brilliantly. The cool people used hg to do stacked CLs so they were productive even when blocked by code review. Fun fact: This particular version of hg with its extensions actually originated from Meta.

We can use jj now, thank goodness. But I still miss my old git workflows + lazygit

I’m no longer at Google and I use jj for my git repo at my current workplace. It’s great as it’s similar to hg but slightly more convenient (no need to manually `hg evolve`). It’s also great that it’s a skill that’s transferable to the world outside google3.

Re: A History of IDEs at Google

#206

Post by rossjudson »

DannyBee wrote: post #100
phreeza wrote: post #38

The most amazing thing to me about Cider-V was that Cider (without the V) actually went away after a relatively short amount of time, when virtually every other internal service that is officially EOL-ed lives on essentially forever.

That is because the Cider team did an amazing job of managing it, and spent tons of time going bug report by bug report to find and fix the blockers stopping people from preferring Cider-V over Cider, instead of the typical Google deprecation approach of "monkey knife fight"

I came from storage, so the monkey knife fight there was between PARMs. Very entertaining. For storage engineering could basically say "Well, figure it out, because if you don't find XX capacity, Google will stop working. Like, all of it."

Re: A History of IDEs at Google

#207

Post by rossjudson »

taeric wrote: post #156
compiler-guy wrote: post #125

Earlier quoted context omitted.

The thing to remember about Google and software is that consumers don't see the vast majority of the software it produces and uses, from the distributed filesystem colossus ( https://cloud.google.com/blog/products/storage-data-transfer... ) to an enormous number of other internal projects just as complicated as that. It's user-facing stuff may or may not be great--and the consumer level flops are legendary--but that…

Certainly fair. But they have tried some amusingly ambitious projects that make it pretty easy to raise eyebrows. Stadia alone is enough to make me nervous on any efforts they announce that are ambitious.

Stadia was pretty technically awesome, and also a rounding error on Google's overall engineering budget.

"Ambitious" engineering means something very different inside of Google. Example: Spanner. Infra Spanner is correctly described as a "generational achievement". Very few people outside of Google have any idea that it exists, or what it does, and that's fine.

Re: A History of IDEs at Google

#208

Post by dotwaffle »

cletus wrote: 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.

Re: A History of IDEs at Google

#209

Post by dotwaffle »

kridsdale3 wrote: post #139
mcoliver wrote: post #57

Meanwhile Google acquired windsurf, released antigravity, and recently handicapped it for Google business workspace users by removing the AI Ultra plan for workspace. So the only real way to use antigravity is either being a Google employee or using a personal account and AI Ultra. https://knowledge.workspace.google.com/admin/gemini/ai-ultra...

As an employee, I'm using Antigravity (CLI version) every day (because we can't use Claude) and it rules. I am way more productive than I was with CIDER-V, which itself was very nice.

/me shudders. cider-v...

Re: A History of IDEs at Google

#210

Post by rossjudson »

LAC-Tech wrote: post #199

This idea of forcing every programmer to use the same IDE is incredibly depressing. I only associate that with really low tier outfits here in NZ, to think that leading companies want to do this too is disheartening (because of course everyone and their dog will copy it). Fight for your autonomy as a dev, because they will always want to take it away.

It's not about forcing everyone to use the same IDE. It's about making sure that there's at least one IDE that everyone can use.

Over time, engineers realize that Code Search is more important than their IDE.

Some of the most productive engineers I know at Google are proud (and adaptable) VIM users, always have been, and nobody is going to tell them they should use anything else. They're also just fine with AI tooling, and fit it right into their VIM workflows.

Post reply on HN