Live data from Hacker News

A History of IDEs at Google

laurent.le-brun.eu

231–240 of 333 posts

Re: A History of IDEs at Google

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

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

Re: A History of IDEs at Google

#232
I still have high hopes that antigravity can work if they have good agentic harness to support with seamless integrations to gemini and 3rd party models.

Current Issues

* It is still buggy. They are fixing it fast, but not as seamless as VS Code. Extensions support is not good. * Harness while it is good, is not on par with others. Harness makes all the difference * Gap between Gemini models and others. Hopefully they catch up soon (IO-2026?)|

If you use Antigravity, what needs improvement to become mainstream?

Re: A History of IDEs at Google

#233
One less-discussed side effect of google's idiosyncratic project structure & tools is that their open source projects can be a goddamn nightmare to work with. Want to make a CI/CD pipeline for your ChromiumOS builds? Have fun trying to make a container that precisely mimicks a Gentoo chroot that changes every 2 weeks.

Re: A History of IDEs at Google

#234

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

> Google acquired windsurf

They didn't. Just licenced ip and some developers.

> released antigravity

Is a crappy, half finished Windsurf fork that constantly coredumps on linux

Re: A History of IDEs at Google

#235
post #75

Man in building Tritium[1] I have always used the analogy that developers would never program in a web-based IDE. Thus, lawyers would never live in a web-based legal IDE either. In exchange for that we’ve paid the onboarding price of trying to get desktop software installed to even run a demo . This is super timely to push us back towards a reality that web may be viable. [1] https://tritium.legal

> developers would never program in a web-based IDE

That's why 80% of developers use a web based VS Code/Cursor

Re: A History of IDEs at Google

#236

Before cider there was Brightly. My recollection was that it was developed by a team in Atlanta and got cancelled before it reached general availability. People were pissed at the time (ex. "cancelling brightly considered harmful"). That died down when Cider delivered on what Brightly had promised. The days of using Eclipse were particularly bleak. These days I use Antigravity for the overwhelming majority of my work…

This is what I'm here for. Indeed the Atlanta team bet it all on Brightly, and while it was so ahead of its time, it didn't get enough of an uptake to satisfy... certain executives in engineering.

They subsequently shuttered Atlanta and it would take five or more years before they'd allow engineers there again.

It was very Google. Lost some truly talented (Hi Bruce!) software engineers who would go on to make terrific software elsewhere.

Re: A History of IDEs at Google

#237
post #75

Man in building Tritium[1] I have always used the analogy that developers would never program in a web-based IDE. Thus, lawyers would never live in a web-based legal IDE either. In exchange for that we’ve paid the onboarding price of trying to get desktop software installed to even run a demo . This is super timely to push us back towards a reality that web may be viable. [1] https://tritium.legal

> developers would never program in a web-based IDE That's why 80% of developers use a web based VS Code/Cursor

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

Re: A History of IDEs at Google

#238
post #62

Earlier quoted context omitted.

I would imagine Android development, with its reliance on simulators for local UI testing, is pretty complicated to shoehorn into a web-based IDE? I think cloud-based IDEs would only really work for anything for which a text or web-based UI suffices. (Which is already quite a lot: that covers code, logs and web pages.) For anything with native UIs, I suppose you could "remote desktop" into an app or a simulator runni…

99% of the Android low level development experience is just the same as coding for Linux. There's no reason Cider-V wouldn't work just as well.

Got it, I was picturing Android app development rather than working on the OS itself until I saw the sibling comments.

Re: A History of IDEs at Google

#239
post #62

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

I would imagine Android development, with its reliance on simulators for local UI testing, is pretty complicated to shoehorn into a web-based IDE? I think cloud-based IDEs would only really work for anything for which a text or web-based UI suffices. (Which is already quite a lot: that covers code, logs and web pages.) For anything with native UIs, I suppose you could "remote desktop" into an app or a simulator runni…

> with its reliance on simulators for local UI testing

I can run an Android app on my phone and have it pop up in Android Studio. I don't see a reason you couldn't do this with a remote simulator or even a remote physical phone.

Re: A History of IDEs at Google

#240

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…

    > There was a policy that forbade having code from this monorepo on your laptop.
Was this due to security and/or technical reasons?
Post reply on HN