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

51–60 of 333 posts

Re: A History of IDEs at Google

#51

Post by ajross »

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…

> But it isn't like [Google] are that much more successful at software projects than any other company?

I re-read this several times trying to figure out where the irony was hidden. But... it's not there?

Re: A History of IDEs at Google

#53

Post by lupire »

StilesCrisis wrote: post #21
compiler-guy wrote: post #6

Earlier quoted context omitted.

Very little development in Google3 happens locally. You aren't even allowed to keep the source code on your local disk, and this is true no matter what OS it runs. (Android and Chromium are different though.) You have access to an extremely powerful remote workstation that from a UI perspective functions almost identically to a local workstation, via Chrome Remote Desktop. Plus, no one builds things locally, even on…

Could you even put all of google3 on local disk if it were allowed?!? You'd need quite a RAID array. I suspect it'd be almost impossible in practice.

There's no reason to pull the entire repo just to build one project. Do you pull all of GitHub to your disk?

Re: A History of IDEs at Google

#54

Post by bsimpson »

nostrademons wrote: post #16

Was there 2009-2014 and then again 2020-2026. I think there are a lot of aspects of IDE use and culture at Google that this post omits. My recollection from 2009-2011 is that emacs and vim were the dominant editors (just as the TV show Silicon Valley depicted), and there was a decent-sized minority using Eclipse and Intellij, both of which had official support for Google tooling. The command line still largely ruled…

I joined in late 2015. Cider was well-known by then.

I'm a UXE, so I tend to use the same tools an external developer might. But I never got the impression that Cider was a recent development.

Re: A History of IDEs at Google

#56

Post by laurentlb »

lzl1234 wrote: post #31

How can they post this obviously internal thing from Google? How can they get clearance from security/IP?

Although the tool is internal, a lot of information about it is not confidential.

As the team had to collaborate with the VSCode team, we got clearance for sharing information about it. The screenshots in the article were posted publicly on GitHub (in vscode issues). You can also find screenshots in https://research.google/blog/smart-paste-for-context-aware-a...

More generally, a lot has been communicated on developer infrastructure at Google.

Re: A History of IDEs at Google

#57

Post by mcoliver »

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...

Re: A History of IDEs at Google

#58

Post by skybrian »

> a team dedicated to the IntelliJ integration was formed around 2015

I don't know which team that was, but to add to that, official support for IntelliJ at Google started quite a bit earlier. I was the second person to join a team writing IntelliJ plugins. We wrote a Blaze plugin not too long after Blaze launched, as it was becoming more popular.

Google tells me that Blaze launched in 2006, so I think it must have been 2007 or 2008.

Re: A History of IDEs at Google

#59

Post by derriz »

barrkel wrote: post #35
wood_spirit wrote: post #14

The last year I’ve been doing all my dev on a vscode VM thingy my company set up. It’s just been getting better and better. It’s like local dev but, tbh, better. It’s at the point where I don’t even install dev tooling locally any more at all. My computer is just a thin client. The aspect I miss is the distributed compilation hinted at in the article. I remember back at the end of 1990s using distcc and things, but t…

You want bazel. Once you've internalized the bazel (blaze) system, you want all builds and tests to work that way.

How do you internalize it?

Our bazel system is full of custom skylark code so understanding the build means effectively reading a bunch of ad-hoc code written with varying degrees of competence and with confusing dependencies. I’m kinda ashamed I don’t have a deep understanding of a tool I use daily - but every time I try reading the documentation I quickly give up.

Re: A History of IDEs at Google

#60

Post by ncruces »

wmedrano wrote: post #47
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…

We've moved on from Git5. Although it was a pain, I kind of liked that Git5 made the monorepo less monolithic to my editor.

Do you mean local checkouts? There's a similar workflow with at least mercurial? Dunno about jujutsu.
Post reply on HN