A History of IDEs at Google
- cletus - 63614 sekunder sedanThere'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 binaries, specifically jars. In the outside world, these dependencies are managed via Ant (very early days), Maven/Gradle or the like.
At Google there's a mono-repo (Perforce/Piper) and you check out parts of it locally and rely on the rest via a network connection (to SrcFS IIRC, it's been awhile). This was neat because you could edit a file locally and the dependencies would just recompile (via Blaze).
So for Eclipse a whole lot of initialization had to be done and the IDE would fall over. A lot. It had a team of ~10 working on it at one point. Then somebody did a 20% project called magicjar. Magicjar took a Perforce client and built all the dependencies as jars that could be imported directly without parsing the entire source tree (which was usually huge). This made it possible, even preferred, to use IntelliJ, which is what I did. Magicjar was great.
Other people actually made CLion work reasonably well with C++ too. That was nice. This was a much bigger undertaking with many more corner cases just given how C++ works (ie headers and templates).
So checking out a client was relatively heavyweight, even with a minimal local tree. And, if you worked on Google3, you had to do this a lot. You might need to do a config file change. This was the real starting point for Cider because it was way nicer to do config file changes with it.
Obviously I don't know where all this went from there. VS Studio as a Cider frontend? Ok, that was news to me. Engineers being unhappy when things change and when the slightest thing works differently is the least surprising thing I've ever heard.
Oh it's worth adding that in my time many people didn't use Perforce (P4) directly. They used somebody else's project, which was a Git frontend for it, called Git5. I believe it was already being deprecated while I was still there. But Git5 modelled a P4 change as a branch so you could play around with your Git commits locally and then squash them into a single P4 change. I actually liked this a lot.
- mcoliver - 62389 sekunder sedanMeanwhile 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...
- anymouse123456 - 5448 sekunder sedanWas at the big G many years ago.
It was long series of incredible and impressive feats of truly singular engineering talent continuously wasted solving problems of our own making that shouldn’t have existed in the first place.
- xenodium - 2426 sekunder sedanWhile most IDEs converged to a unified web solution, pockets of devoted users continued to volunteer improvements/integrations for their preferred editors.
During my time there, a relatively small, but fairly active Emacs group, would often share tips, tricks, and elisp integrating the latest internal tools.
- malkia - 46755 sekunder sedanXoogler here (2014-2017). My team (part of Ads) used primarily Java, and we used the Eclipse, then we started switching the IntelliJ.
Cider was used also a lot, but I've heard even back then some folks were free to use whatever they like - vi, emacs, you name it.
- setheron - 4832 sekunder sedanI'm at Meta now but I was at Google as well. I really enjoy contrasting the two toolchains and where they rise and fall short of each other.
I must say the debugging experience at Meta has been spectacular.
I liked the way CitC exposed Snapshots and easy to make projects.
(+ A bunch of other dozen opinions)
I was also at Amazon circa 2011 and it's funny to think about the experience back then. I remember i toiled to get Eclipse CDT to work whereas everyone else worked without any language intellisense. The work paid off though and I was able to drop P95 of the real time service I was on by 50% with the aided code intelligence + hooking it into callgrind.
- piker - 60865 sekunder sedanMan 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.
- phreeza - 63680 sekunder sedanThe 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.
- ryukoposting - 22905 sekunder sedanOne 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.
- StilesCrisis - 66560 sekunder sedan"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.
- kjgkjhfkjf - 43149 sekunder sedanWhen 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 their unusual situation, but it's worth keeping in mind that their approach probably isn't ideal in ~most modern dev scenarios.
- wood_spirit - 65723 sekunder sedanThe 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 that never seemed to happen in the Java world and the tooling like maven etc is structured to make everything one long dependent chain. Shame.
- exclipy - 43840 sekunder sedanI jumped from Google to Facebook on 2019 and while I had thought Google had best in industry developer tooling, Facebook had it better.
Google’s dinky browser based Cider was cute but Facebook in its transition from Atom to VS Code was far ahead. Google might have invented asynchronous web based code review with Mondrian and Critique, but Facebook’s Diff was better with its stacked diff support. Google’s Buganizer was outdated and clunky compared to Facebook’s Tasks.
I left Facebook the year after but I do wonder where Meta’s tooling is up to nowadays. Is it still a glimpse of the future?
- wmedrano - 61944 sekunder sedanLuckily, they still support the text editor + CLI tools workflow so I can still use Emacs effectively.
- compiler-guy - 66611 sekunder sedanThat 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 turned them off, later updates would turn them back on. This is very good for your adoption metrics, but might not tell you exactly what you want to know about engineer happiness.
Such a dominant IDE also allows management to ignore the long-tail of users who aren't using it.
- j2kun - 65104 sekunder sedanI am very opinionated, but I really don't like Cider V. I have been using neovim at Google since 2017 and it's been great.
- taeric - 65869 sekunder sedanThe 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 projects than any other company? They are still largely an ads company, no?
- dogscatstrees - 44025 sekunder sedanI think it's also worth mentioning Piper, Critique, and the infamous monorepo.
[1] Piper: https://en.wikipedia.org/wiki/Piper_(source_control_system)
[2] Crituque: https://books.google.com/books?id=V3TTDwAAQBAJ&pg=PA399#v=on...
[3] Monorepo: https://dl.acm.org/doi/10.1145/2854146
- m3drano - 64924 sekunder sedanThe name Cider is not from Cloud IDE, stems from Critique (the code review), which is addressed via cr/ - Cider is the IDE in Critique: cIDEr.
- ncruces - 67283 sekunder sedanThe thing I most love about Cider-V is that moving between it and (often remote) VSCode when working outside google3 becomes mostly painless.
- lzl1234 - 64190 sekunder sedanHow can they post this obviously internal thing from Google? How can they get clearance from security/IP?
- w10-1 - 64091 sekunder sedanI 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 reflects success rather than Google policy.
I'm interested in how tooling conditions developer expectations more broadly. I'd love to see a comparison of Linux OS development (all local+open+git, open but contributor hierarchy) vs Google (monorepo+required tooling, pre-allocated authority) from someone who's done both.
- insumanth - 24616 sekunder sedanI 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?
- bhickey - 52139 sekunder sedanBefore 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.
- skybrian - 62175 sekunder sedan> 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.
- tomaytotomato - 65071 sekunder sedanDo Java engineer at Google not use IntelliJ?
- SimianSci - 63896 sekunder sedanThe biggest question on my mind is how the use of Cider V is being affected by the officially ordained Antigravity. Is the trendline starting to show that its adopting more Antigravity style tooling? or is this causing some sort of rift?
- tantalor - 53386 sekunder sedanGoing from Cider to Cider-V was a huge loss for user experience. I just can't get used to the VSCode UI. The in-house stuff was much better.
- kylecazar - 66581 sekunder sedanI was surprised to read that Chromebook use at Google was common for engineers. Even if developing remotely I had assumed they'd opt for the most powerful machine possible.
- dobx2010 - 56600 sekunder sedanJava backend development got pushed to Cider-V from IntelliJ to a degree because the company stopped supporting IntelliJ internal plugins, so not all developers organically moved to Cider-V (and some still use Android Studio to do the non-Android Java development). The forced move got a lot of resistance because of lack of power refactoring features among others in Cider-V.
- aboodman - 55993 sekunder sedanI was there 2004-2014 and never used an IDE the entire time. From my perspective the most popular editors were emacs and vim. Life was probably different in the Android and Java areas, but there was also a massive chunk (50%+?) of people writing C++ and Python, and I think IDE-less is/was the standard for those folks.
- hnthrowaway0315 - 59992 sekunder sedanI can't imagine people enjoying web based IDEs. I used to work for a company that has everything made internally, including IDE -- they used the same method OP described -- using VSCode on web. The experience is horrible.
I guess maybe it was fancy back in mid 2010s, but my experience was a couple of years ago.
- 9front - 41907 sekunder sedanIs the V in Cider-V the Roman numeral 5 or V like in Visual?
- nostrademons - 65568 sekunder sedanWas 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 though, even though the official Google developer workstation was Goobuntu, Google-flavored Ubuntu. This reflected the overall developer population of the time.
I think Cider actually was invented a little earlier than the article describes. I have vague memories of some engineers experimenting with web-based IDEs that would integrated directly with Critique (the code-review software) as early as 2013-2014. Its use was not widespread when I left in 2014; there was still the impression that it wasn't powerful enough for daily driving.
When I came back in 2020, emacs/vim use was much lower, again probably reflecting differences in the general population of developers. Many more of the developers had been trained in the post-2010 developer ecosystem of VSCode, IntelliJ, etc, and this was reflected in tool usage at Google too. I'd say IntelliJ was the dominant IDE, with Cider a close second and Cider-V just starting to take market share. You still had to pry emacs and vim from a grizzled old veteran's hands.
By 2022 I'd transferred to an Android team, and Android Studio with Blaze was the dominant IDE, even as general IntelliJ usage in the company was falling. Cider just didn't have the same Android-specific support. Company-wide Cider-V was growing the fastest, taking market share from both IntelliJ and Cider-V.
By 2024 Cider-V was dominant and there started to be a concerted push to standardize on it, particularly since new AI agent tools were coming out and they couldn't be supported on all editors that Googlers wanted to use.
As of my departure in 2026, the company-wide push was to standardize on Antigravity [1], which, as I understand it, won a turf war within the developer tools org and got blessed as the "official" Google AI coding agent. This also has the effect of concentrating developer time dogfooding Google's external AI coding offering, which hopefully should improve its quality. There's still significant Cider-V usage, but it's dropping, and execs are pushing Antigravity hard.
- s-xyz - 46882 sekunder sedanI wonder if the IDE will eventually die, and be replaced by something fundamentally different, like Claude Code Desktop, Codex Desktop, Lanes.sh, or Factory.
- jason1cho - 64932 sekunder sedanInitially Cider was branded as a light client that opened much faster than traditional IDEs.
Now, ironically with so many extensions and LLM computing, users seem to forget that they chose Cider because of its lightweight.
- istillwritecode - 41493 sekunder sedanxoogler from 2005 to 2018. People in developer tools always wanted a mandate to use their tools when their tools didn't gain enough users.
- fleaflicker - 44491 sekunder sedanAnother real killer feature of web-based IDEs is zero setup for new engineers.
You won’t have to spend a day fiddling with your local env. Everything just works immediately.
There are commercial alternatives like GH codespaces but not as good as Cider-V.
- LAC-Tech - 38763 sekunder sedanThis 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.
- squirrellous - 44060 sekunder sedanSomething that amazed me around the time Cider V was first introduced is that some folks have been at Google for so long, they have never used VSCode, and didn’t recognize the UI at all.
- VirusNewbie - 65627 sekunder sedanCider-V is very nice. It's VSCode so all the extensions just work - Vim mode, themes, etc.
It's also nice that it stores all my preferences in the cloud, so switching machines is seamless (helpful when my macbook broke a couple weeks ago and I had to use a loaner chromebook for a day).
It's also well integrated with google3 and codesearch, and seamlessly runs tests on remote machines with tmux integration and all.
Not all of google tooling is my favorite (like their source control), but the IDE is great.
- alwinaugustin - 61799 sekunder sedanReal IDEs are built by Jetbrains.
- LadislavSopko - 8637 sekunder sedan[flagged]
- rudraneel93 - 18795 sekunder sedan[flagged]
- rudraneel93 - 18647 sekunder sedan[flagged]
- hona_mind - 34253 sekunder sedan[dead]
- - 61165 sekunder sedan
Nördnytt! 🤓