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 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.
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 trace referenced, and overall has a million little features optimized for reading code.
We also have a code reviewer tool, and a separate tool to run and view CI runs.
So what’s left for the editor? Syntax highlighting?
I would tend to view code, run tests and CI, and review in separate tools specialized for their specific use case. The code editor was just a place where I would type in my changes.
I’d imagine this workflow feels weird to people who learned in one-stop-shop IntelliJ and GitHub world. But I can’t emphasize how much better these other tools were compared to GitHib. So a code editor that also lets me read, review, and test code didn’t really matter for me when I had a collection of smaller tools specialized for each individual task.
To make this more concrete, the Chromium source code browser has a subset of the functionality of the internal Code Search tool. For example, you can left click on symbols to go to reference and right click to find all references:
This...I noticed a real productivity increase when going from Cider/VSCode to JetBrains/IDEA/IntelliJ for Kotlin code editing. Having a "real" IDE was still a plus, if just for the better code completion.
AI has mostly changed the way I write code, I guess, so I rarely use JetBrains anymore, but a few years ago it was clearly a win to use a real IDE at least for Kotlin programming.
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"
Every large tech company of 80s, 90s & 2K (Google, eBay & all) have similar history when it comes to IDE, Source Control, Build Systems etc.,. This is not specific to Google.
I recall a couple of JetBrains staff visiting in 2008 to see IntelliJ's struggle with the size of checkout for AdWords. Soon after the reindexing front/center dialog moved from blocking and center of window, to a status line message that was non-bloking of edits at the bottom of the window. It may have been due anyway but was shown as problematic in the same moment.
I started a touch before this in London. I recall before Blaze and git5 - every morning we had a ritual of checking out google3 and making sure we could get some sort of build working for the day so that we could then attempt to write some software on top of it. The builds in play were “Mach” and “quickie” or something like that. It was so painful we used to agree that we wouldn’t grab food or coffee or anything until we’d worked out what CL we should sync to for the day to do some work on.
Pair programming was very in vogue and I used to get in a little later than some which was a great excuse to just hop on someone else’s machine who’d already gone through that pain
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.
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.
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.
It was a sad surprise last week when we tried to upgrade the workspace AI plan for some of our team members to Ultra and it was gone. We're moving to Claude/Codex.
Yeah I've considered that as well. Was loving having everything in the same ecosystem and have been pleased with the Gemini 3.1 models. I still think this is a blip and Google will come around. It doesn't make any sense.
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.
I can guess: I am 3 weeks into a 4 week Ultra subscription and the amount of Claude Opus and Gemini Pro tokens that they give you on the subscription is very generous - I feel like I have been gorging on tokens, tidying up 25 years of my open source projects. When my one month subscription runs out I will miss it.
It's really baffling. Zero transition plan. I could see them offering something to businesses and not consumers. But the other way around has me scratching my head. I figured out how to get it working again with code assist, a gcp project, some custom json and a bunch of clicks in various places but even with plenty of quota for the Gemini models in gcp, antigravity fairly quickly told me I was out of quota for a week so they also have a tracker for antigravity quota that's separate.
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.
Hi Drew, I remember your "Show HN" from a while back and have been secretly rooting for you ever since! (I'm not a lawyer but for some reason I have many friends that are, and now I happen to do work for a firm in the legal publishing sector, so I often hear about how terrible "word processing" can be and think there've got to be better tools!)
May I ask, how are things going? Also, will your IDE always be focusing on transactional law or have you considered expanding to other legal areas and/or markets?
Hi! It's a super interesting time to be in legal tech. Thank you for asking.
When this project got started, "VS code for transactional lawyers" was the target. We pretty well have that on offer at this point, but it sits in a weird spot making it harder to sell than it would be in, say, 2024. Right now, "AI forward" lawyers are spinning out of law firms in droves to start "AI native" firms backed for example by YC. They're so comfortable with Claude that they for the large part bypass a need for Tritium (or at least they think they do ;). OTOH, large law firms are inundated with legal tech products right now and have a hard time even understanding how an IDE benefits their lawyers. We're also trying to stay away from VC funding (other than from a certain awesome one ;), so we're missing a key signal for enterprise buyers. As I mentioned above, it's super hard to even set up a hands on demo because we have to get the desktop app installed on their infrastructure. But I'm shocked to learn that Googlers are happy to work in a browser, and distributing Tritium via browser is trivial, so we're going to 180 on that right here and now.
That all said, we eliminated the "free tier" as advised back in the Show HN thread, and we've managed to find a very small market in individual users. We're also finding some opportunities with the AI natives using an "unreal engine for legal tech" model that makes Tritium source available and handles the boring editor-related parts of their innovation.
I should probably do a post on this, but there's actually a topic we're working on that perhaps the HN audience will find even more interesting... coming soon!
[edit: I realized that I haven't responded to your question re: other markets, but accidentally did with the hint. We have some ideas.]
The main thing holding most people back from web-based IDEs is restricted filesystem and tools integrations, but cloud office suites are extremely popular. Google has excellent infrastructure for distributed build and test cycles built into Cider to go along with the entirely remote version control system.
Best of luck on your web-based demos! Dropping people into a working dummy environment with a few tutorial prompts should really help conversions.
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."
I dunno, there's certainly a lot of monkey knife fight deprecations, but there's a lot that are handled pretty well.
If we're talking about the source side of things, p4->piper/citc was done well. cs (get) -> grimoire was done well. I'd like to think we did a pretty good job of grokv2-> Kythe, though we did drop a few clients of grokv2 who were wayyyyyyy the fuck up xkcd/1172 creek (we did try to help them in the right direction, like offloading onto direct blaze depserver queries).
I guess those are all close in the org to cider, so maybe that's just how dev infra deprecations used to go.
Initially I had thought so too. But later I realized that it’s quite easy to do so when you force-deprecate the old product. There was no real choice, the old IDE simply stopped working after a certain cutoff date. Adoption metrics felt forced and pushed, but were presented as if users were actively and willingly choosing the newer IDE.
I feel like core dev team learned a lot about actually enabling a web based ide for line 100k engineers across the globe for a gazillion line mono repo. ciderv is really just a skin for the amazing infra. Which is also why I think there was less resistance to the change
Yep, I made my own! (Xoogler 2017-2023) this is my noogler IDE story, one of my favorite, proudest hacks!
I developed a fork of the IntelliJ IDE on my second week at google out of raw frustration over latency.
At the time I was commuting 2-3hrs/day SF<>MTV on the gBus.
Connectivity on the bus wasn't optimal, and there was high latency. Cider didn't have deep integration, and wasn't able to let me explore and understand the internal APIs effectively. I found it easier to enter a debug session within Intellij then 'vibe' and explore the internal apis via superComplicatedObject.ini<tab>.
Faced with an alien architecture + ADHD-unfriendly flow-crushing remote desktop latency -- and the lack of discoverability, I started hacking at it and without any knowledge of the system and architecture. Just tracing Intellij execution, subprocesses and network calls.
I was able to hack together a prototype in a few days that allowed me to run IntelliJ on my Mac, while the heavy bits ran on my corp desktop. The system would mount the remote filesystem over sshfs, would monitor and patch network connections and setup transparent shim binaries. Half of Intellij was running on the Mac (the front end) and the other half ran on Linux. Intellij didn't "know" that that it was running on a mac. This was initially implemented in a ~250 line shell script that patched everything.
It was called MDProxy[1] and ended getting adopted and supported during COVID as more development went remote. This became a source of many peer bonuses and spot bonuses. circa 2017* remote coding options at the time:
typing | code
latency | integration
--------------------------
cider low | meh
mdproxy low | great
ssh+vi med | meh
rdp+iJ crushing | great
Dude I was there 2019-2022 and mdproxy was a huge win when I realized I could work while traveling. I remember following some incantations on someone’s personal page to get it running. Then covid happened and I was ahead of everyone for a few weeks because I already had been doing real work on my laptop. Thanks!
Yeah, I was working out of the Sydney office. Almost everything was incredibly slow due to that latency, not just chromoting but also just accessing most sites through beyondcorp.
oh wow! that sounds awesome! (I guess I left around the time you were starting)! I was based in LAX (so no G-Buses for us, but I had to visit MTV often - like once twice a month, and enjoyed getting on one of them)). Kudos!
I’m surprised you find ssh+vi having medium typing latency. I have ssh’ed to either my desktop to (later) my cloudtop and latency has always been great. The ssh latency is good enough that I can run X forwarding to launch graphical instances of emacs and gvim. The latency was basically unnoticeable.
Later I rented a vacation home in South Lake Tahoe and worked remotely. It was only then that I realized it had terrible latency.
"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).
There is in fact a version of cider that does work for folks working outside of google3, such as android. It's not as seamless, but it has been getting better and tries to recreate the google3 experience.
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 running in the cloud but at that point you might as well run that locally and cut out all the issues introduced by networking.
For what it's worth we still use Android Studio as well internally, it is better and faster for doing specific UI stuff because of the tooling and visualization.
On the flip side the Google monorepo is a pretty cool thing and you get used to switching between projects and languages within the same commit chain pretty often. This is part of the reason the cloud IDE is so popular because it's one common editor across many languages compared to language specialized IDEs like Android Studio.
Regarding networking, it's not a big issue day to day. The infra team does a really great job building tools that do efficient caching and integrate well over the network.
"Android" here refers to the Android operating system, which (like Chrome) has its own separate development stack. Most of Google's Android apps are developed using the main google3 stack described in the post, or at least were when I was there.
> For anything with native UIs, I suppose you could "remote desktop" into an app or a simulator running in the cloud
This does exist. The network isn't the main problem. The Emulator has to run under nested KVM. That + graphics rendering on the CPU makes it not so responsive. It's useable enough in many cases though.
iOS apps at google are developed via ciderv that had a connection to your local mac, and it's amazing. All code editing is "online" and builds are cached, but simulator runs on your local machine. I'm convinced the apple dev env at google is like 100x better than apple's
> 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.
I 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?
I have never worked at Facebook but I have always thought of Critique as the best code review tool I’ve used. It’s way better than GitHub. A few things I miss: (1) it has convenient and intuitive pure-keyboard navigation; (2) you can reply to code review comments in a pending form and then publish them after you update your code, because in the common case you address code review comments by updating the code; (3) until recently GitHub wouldn’t allow you to comment on lines far away from the changed lines but Critique has always allowed it, because obviously this is an important use case when the reviewer needs to point out the changed code affects some other regions; (4) it had support for diffbase so it displayed stacked CLs fine.
Critique had had a redesign between end of 2019 / start of 2020. I didn’t recall adding any significant features but it merely modernized the UI. So did Buganizer and Code Search. So if you thought the UI was clunky well it had been addressed.
I left Google end of 2022, but we already had the mentioned new version of Cider based on VS Code for a few years before that. It's possible FB did it first, but I don't think Google was far behind at all. I'm fairly certain there was the new VSCode based Cider by early 2020. Certainly was by end of 2020 and entirely common by the time I left.
(I didn't get to use it much because I worked on embedded stuff that was on the Chromium stack and in git, not in Google3)
Buganizer (v1 and v2) was delightfully primitive and simple. That was the point. PMs couldn't play games with it.
There is enough flow of engineers between the two companies that many of the things Facebook has done better have been copied by Google. I think in many ways it goes both ways.
I jumped from Google to Meta in 2022 (Worst. Timing. Ever.) and by that time Google's IDE had pretty much caught up. Android app development at Meta was super painful because of the repo size. My good morning routine was to kick off a 40 minute sync, and then get coffee and wander the building while I waited.
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.
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.
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 their unusual situation, but it's worth keeping in mind that their approach probably isn't ideal in ~most modern dev scenarios.
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.
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 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.
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.
Maybe, but I feel like an article I’ve read many, many times is “we hired one or more Xooglers for our startup and this turned out to be a catastrophe because they insisted on trying to bring blaze/bazel with them and it nearly destroyed the company.” It’s always bazel specifically in these articles, never any of the other internal Google stuff like Spanner.
This is the other way people work at Google. You have a Vm and then connect IDE of choice to it via SSH. But honestly it’s a lot more effort that just using Coder
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 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.
Visibility doesn't always get you value though. See the many companies that unify their ticketing to something like Jira, and end up running reports on in. The actual accuracy of the aggregates is rarely great, and instead leads to people doing "jira optimization" to make reports look good.
I once worked at a place where VPs were looking at sprint burndown charts, and asked what happened if the line didn't look a lot like the line expected by JIRA. The telemetry is therefore often a curse, as any metric becomes a target. How many companies today have KPIs about having automated code reviews, which are then ignored by the devs, because said reviews are just wrong on almost everything?
The learnings of Seeing Like A State don't apply just to governments.
You have to be very careful in management to not create perverse incentives. I like to use change control processes as an example. In theory, a super strict change process for every single change is great, because it'll ensure everything gets reviewed thoroughly. In practice, that leads to people flouting the change process as much as they think they can possibly get away with, because it becomes a serious impediment to getting work done. A more moderate change process would have higher compliance, and actually lead to more oversight, than a super strict one.
> 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.
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 projects than any other company? They are still largely an ads company, no?
I mean, ads is 73% of revenue. Of the rest, ~60% is Cloud, ~35% is hardware and subscriptions and app store fees.
So, sure, lots of spots for software there. But still nothing that would make me think of them as a software company. Or, worse, a lot of software that I don't have a strongly favorable view on. :D
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.
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 complaints about AWS back in the day. It wasn't a lack of ML offering in AWS that made Amazon Photos less useful than Google's photo offering. Despite what some internal folks would say.
Do they have more success in software products than other companies, though? Most of the software many of us know from them, were acquisitions. They still do heavy acquisitions. Notable that they have double the acquisitions of Amazon. They are on par with IBM. A colossal amount of money spent to make things happen.
So, again, are they that much more successful at software than other companies? They have more hilarious flops than any other company.
Don't get me wrong. I still use some of the stuff. I don't hate them. I don't even think they are particularly bad at things. I just don't think they are any more successful than other software companies. Specifically at the software side of it.
Google is an ads company with a large amount of infrastructure to back it up.
Sure, the money is mostly in ads, but serving searches, AI, youtube, and all the rest at the scale Google does it requires a technical tour-de-force. Does Google do it better than everyone? Absolutely not. But it does it better than many.
Certainly it isn't the _only_ way to do it--other companies also manage to do it. But not all that many at the same scale. It's an existence proof that you can.
Most of what they do really really well, though, is accomplished by massive amounts of spending. That isn't a knock on it.
Consider that they spend more on trying to build up and support this central IDE than most companies dream of losing in productivity to not having this.
There are things people do in Borg that when ported to our own public cloud kills entire regions. Sure you get limited choice but things work at global scale without thought
But the downside is that you do get the Cider team constantly messaging and asking for reasons you won't switch. I gave feedback that their Vim bindings were broken (it would sometimes fail on holding down directional hjkl for no reason) but I'm not sure if they've fixed it since I left in 2023.
Cloudtop to run builds, g4 commands, etc., and srcfs / srcfsn to actually write code. (caveat: I have never used neovim, so I don't know if that is different).
Spin up one in the US central region instead of an instance near your satellite office. The bottleneck is usually not your shell connection to the instance but the connections from the instance to all the infrastructure that's mainly based in the US.
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.
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.
I'd love for more screenshots should anyone have and can share. I still don't get a great picture of how it's running in the browser and I find UI choices fascinating. But I imagine I'd need an NDA to see the settings/options :')
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 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.
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 costs of engineers are very different. I'm really unsure why you would think otherwise.
Unlike others, Google is also remarkably good at quantifying the actual value something provides in developer productivity/etc. Most engineers handwave this tremendously. Google has an amazing amount of telemetry. So i laugh when you talk about "the leverage over developer productivity" because the vast majority of companies i've worked at or talked with have almost no useful idea about their developer productivity (IE can't even account for the majority of their developers time at work), or how to invest effectively to do something about it. They can often account for <30% of time developers are spending at work, etc.
As for perspectives - there is plenty of sentinment and other data. Cider is overall one of the top 5 most loved tools at Google, and had well over 90% developer satisfaction IIRC.
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.
Cider-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.
Not anymore they don't (usual caveats apply: no longer work there; big company so YMMV).
It was an option for a while, but getting it to work with the remote filesystems for the monorepo was a bit annoying (e.g. you'd create a new project in IDEA where you'd have to pick what parts of the monorepo you wanted to have in there, but it all happened up front).
> 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.
Blaze was started late 2005 or early 2006. Eclipse+IntelliJ was also at that time.
The IntelliJ blaze plugin was already started and out when I joined in 2007.
My first job was to keep it from being rewritten yet another time, get teams to use it, and also keep it from being cancelled.
I'm not sure about the dates.
At some point (2014?), the use of IntelliJ was discouraged in favor of Eclipse. One year later or so, the decision was reversed and the effort focused on IntelliJ (and Eclipse were considered deprecated).
IntelliJ was unsupported ("community supported") when I joined in the summer of 2015. I built a new protobuf editor plugin during that period as a side project, mostly for myself, which suddenly became used by thousands of Googlers when IntelliJ became the supported IDE again in ~2016?
I eventually handed it over to JetBrains and I think it ships by default with IntelliJ now.
I 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.
While 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.
I 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.
From the article:
“ Cider was a light client that opened much faster than traditional IDEs. All the magic happened on a backend that indexes the entire codebase, so that all the data was ready whenever someone opened the webpage.
”
Sounds like all other editors were slow compared to Cider.
I'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.
The 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?
If you are very into agentic coding then in 2026 you're using Antigravity. But if you are less into it Cider-V has a slightly less powerful (e.g. no web browser harness, no multi-agent parallelism) version that is backed by the same implementation. Since both are built on VSCode this is ~ trivial.
In my experience, antigravity IDE is much less seemless compared to Cider-V. I completely moved to using web-based antigravity for the agent and using cider-v to make manual changes and viewing code.
Something 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.
100% up-to-date VSCode is still pretty trashy, IMO. It's a mixed bag of plugins without cohesion, no awareness of code other than what that mixed bag attempts to provide (poorly). It is and always has been little more than a progressively more complicated mobius loop of autocompletion-oriented UI experimentation.
Ah, I feel so much better now. ;)
VSCode never made it past the first 10% of what Eclipse did (does). VSCode did succeed at being something for everybody, available everywhere.
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?
I 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.
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 that machine. There is a huge, absolutely amazing distributed build system that everyone uses for everything. (Again, Android and Chromium are different.)
So you don't really need a powerful local machine. I held out for a long time--there were a lot of growing pains in the early days. But eventually it got really, really good.
I can understand Android (including the Linux kernel) being "too big" and "too separate" to go into Google3, but why Chromium? When it was forked from KHTML/WebKit it was probably not that big compared to the rest of Google's codebase.
For most of my time here I used exclusively Chrome OS, and switched to it for personal use as well. My daily driver for years was a bright red Samsung Chromebook Galaxy (the first gen with the actual metal case). Literally none of my work is local, and it could run Secure Shell, Cider-V, and Docs as installed PWAs with their own taskbar items, etc. It was glorious.
When it finally failed in the most annoying way possible (the touch screen, which I do not use, started creating phantom clicks in the upper right corner of the display) I went looking for another Chromebook that was light, powerful, and well-built. Finding none, I now use MacBook Air and weep for the time I lose every time it needs an OS update.
Ive had that issue with touchscreens before and was able to disable the driver for it. Linux so not sure if possible or how on a chromebook but an option.
How common? I'd wager most people still use a mac, followed second, but far by regular goobuntu laptops. Chromebooks goes 3rd because Windows is practically banned.
FWIW I don't think this is accurate (was kinda true in the 2010s?). I wouldn't be surprised if it's almost easier to get windows laptop than linux one now.
When I joined, I started with a MacBook and lost it within three months :(
Afterwards I was issued a 12" Pixelbook and it was surprisingly much more usable than I had expected! I could ssh into a Linux box for running builds and tests. Cider worked perfectly. It was snappy enough to serve as a thin client even on a 4K screen.
Chromebooks are pretty much only good as thin clients, so much so that when I have the money I plan on building a powerful rackmount workstation and connecting to it via chromebook/box
I do most of my development on a MacBook air and a Chromebook. The ~only thing I do from my local machine is ssh into a beefy workstation and use chrome.
From what I'd heard contractors get issued as little as a Pixel tab and dock? Everything else is in the cloud (either gLinux desktops or cloud shells) AFAIK.
Java 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.
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 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.
How many new googlers use vim or emacs do you think? I can imagine at least a small amount of new vim people since vim will always be popular, but I would love to know if more than a handful of new googlers a year use emacs
I've switched to emacs and I no longer use IDEs. This is because I do all my edits, as a personal policy, via LLM. I mostly use emacs for magit (I work on a git-on-borg repo).
I joined gdm recently, and previously used (neo)vim exclusively. Begrudgingly Cider-V is very, very good. It might be possible to get by without it, but the system is so locked down you’re going to make a lot of sacrifices. (very few authorised extensions, codebase is so large it’s going to break whatever tools your used to using anyway, no git)
I’m well thinking I may as well trade my brick of an m5 pro for a 13” chromebook, it’s a strange time.
Famously Jeff Dean uses emacs. Emacs integration to internal systems (source code, code search, LSP, build, etc) was super solid when I was there ~2020.
There is an internal website that tracks statistics of tool use, where “tool” is defined liberally and includes emacs. It would be tracked if you just (require 'google) somewhere in your initialization code.
I don't think so, I think they forked VS Code directly or possibly forked Windsurf which forked VS Code. Hence the turf war and internal controversy; a lot of the effort on Cider-V got dropped on the floor, right at the height of Cider-V's popularity when they were getting large amounts of features.
Duckie does still exist, and is probably one of the most used (and useful) AI tools at Google. Yes, it's just a Gemini wrapper with access to all the internal documentation. I wasn't doing daily development when I left so I don't know if it ever got into Cider-V.
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.
> Over time, engineers realize that Code Search is more important than their IDE.
You nailed it.
One particularly hard problem Google faced w.r.t. IDE integration was the intersection of thousands of RPCs defined by protobuf declarations => generated protobuf code in 10 different languages being dong transparently by blaze + not checking in generated code => where does the IDE based indexing find the generated source files, and then tie that back to the original .proto file declaring the RPC declaration. Blaze had the information available through a query, but needed ways for the user (the IDE) to optimize the query plan so that it could deliver just the proto related dependencies with sub-second response time to keep the human users happy.
Once you found the .proto file that defined your data they could leverage the the monorepo and search over it. Let's say I am a Java programmer working on a server endpoint and want to change the format of some data I am stuffing into a protobuf. I could find the original declaration, and then find all the instances of objective-C code that our iOS apps were using to consume it. Trivially easy with the combination of global code search and a global dependency graph.
Caveat: Code search and a monorepo let you do some amazing things. But there is a LOT of cost which Googler's tend to nostalgically gloss over. piper, citc, kyte, critique, and depserver* represent (wet finger in the wind guess) probably $100M of development effort.
Context: Googler from 2007-2025, worked on API serving infrastructue, desktop apps (yes, we checked out source code to windows laptops), blaze/bazel, and a few others. I've seen all the developer tooling problems.
*depserver is a essentially a service that holds the entire blaze dependency graph every file up to every buildable object across the code space. That drives the automatic testing infrastructure.
From what I've heard rumor-wise, everyone has abandoned the web UI editors and are now using (or being told very loudly by management to use) Antigravity exclusively for everything.
I wonder if the IDE will eventually die, and be replaced by something fundamentally different, like Claude Code Desktop, Codex Desktop, Lanes.sh, or Factory.
Been using Cider for two years now. Early on I struggled, trying to use IntelliJ, and even tried the thin client version — but both are basically in maintenance mode. Cider is the de facto standard. It really is the best IDE in terms of integration with internal tools, but it also inherits Google internal tooling’s general disregard for UX quality and aesthetics.
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 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.
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 trace referenced, and overall has a million little features optimized for reading code.
We also have a code reviewer tool, and a separate tool to run and view CI runs.
So what’s left for the editor? Syntax highlighting?
I would tend to view code, run tests and CI, and review in separate tools specialized for their specific use case. The code editor was just a place where I would type in my changes.
I’d imagine this workflow feels weird to people who learned in one-stop-shop IntelliJ and GitHub world. But I can’t emphasize how much better these other tools were compared to GitHib. So a code editor that also lets me read, review, and test code didn’t really matter for me when I had a collection of smaller tools specialized for each individual task.
To make this more concrete, the Chromium source code browser has a subset of the functionality of the internal Code Search tool. For example, you can left click on symbols to go to reference and right click to find all references:
https://source.chromium.org/chromium/chromium/src/+/main:ipc...
8 replies →
> It’s super fast, is connected to language servers and can actually trace referenced
Nit: not connected to language servers, it's connected to Kythe. LSP doesn't have the same kind of functionality.
This...I noticed a real productivity increase when going from Cider/VSCode to JetBrains/IDEA/IntelliJ for Kotlin code editing. Having a "real" IDE was still a plus, if just for the better code completion.
AI has mostly changed the way I write code, I guess, so I rarely use JetBrains anymore, but a few years ago it was clearly a win to use a real IDE at least for Kotlin programming.
1 reply →
What tools available to the public would you say is similar to this workflow?
5 replies →
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"
Every large tech company of 80s, 90s & 2K (Google, eBay & all) have similar history when it comes to IDE, Source Control, Build Systems etc.,. This is not specific to Google.
[dead]
I recall a couple of JetBrains staff visiting in 2008 to see IntelliJ's struggle with the size of checkout for AdWords. Soon after the reindexing front/center dialog moved from blocking and center of window, to a status line message that was non-bloking of edits at the bottom of the window. It may have been due anyway but was shown as problematic in the same moment.
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.
5 replies →
I started a touch before this in London. I recall before Blaze and git5 - every morning we had a ritual of checking out google3 and making sure we could get some sort of build working for the day so that we could then attempt to write some software on top of it. The builds in play were “Mach” and “quickie” or something like that. It was so painful we used to agree that we wouldn’t grab food or coffee or anything until we’d worked out what CL we should sync to for the day to do some work on.
Pair programming was very in vogue and I used to get in a little later than some which was a great excuse to just hop on someone else’s machine who’d already gone through that pain
> Engineers being unhappy when things change and when the slightest thing works differently is the least surprising thing I've ever heard.
Gold.
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
5 replies →
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.
I still have nightmares about eclipse sometimes.
There are mercurial and jujutsu frontends now.
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...
It was a sad surprise last week when we tried to upgrade the workspace AI plan for some of our team members to Ultra and it was gone. We're moving to Claude/Codex.
Yeah I've considered that as well. Was loving having everything in the same ecosystem and have been pleased with the Gemini 3.1 models. I still think this is a blip and Google will come around. It doesn't make any sense.
2 replies →
[dead]
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...
Google employees can’t use antigravity. There is an internal version of it which has an agent which is shared between Cider and it.
It's the same thing with a different name and different default settings.
4 replies →
> https://knowledge.workspace.google.com/admin/gemini/ai-ultra...
It's been a while since I visited any google pages and I'm shocked how insipid and soulless their UX still is.
> 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
Anyone care to speculate what the internal reasoning is?
Google has a rich history of product mismanagement. It would be a shame and legacy ruined if it were to change.
1 reply →
I can guess: I am 3 weeks into a 4 week Ultra subscription and the amount of Claude Opus and Gemini Pro tokens that they give you on the subscription is very generous - I feel like I have been gorging on tokens, tidying up 25 years of my open source projects. When my one month subscription runs out I will miss it.
It's really baffling. Zero transition plan. I could see them offering something to businesses and not consumers. But the other way around has me scratching my head. I figured out how to get it working again with code assist, a gcp project, some custom json and a bunch of clicks in various places but even with plenty of quota for the Gemini models in gcp, antigravity fairly quickly told me I was out of quota for a week so they also have a tracker for antigravity quota that's separate.
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
Hi Drew, I remember your "Show HN" from a while back and have been secretly rooting for you ever since! (I'm not a lawyer but for some reason I have many friends that are, and now I happen to do work for a firm in the legal publishing sector, so I often hear about how terrible "word processing" can be and think there've got to be better tools!)
May I ask, how are things going? Also, will your IDE always be focusing on transactional law or have you considered expanding to other legal areas and/or markets?
Hi! It's a super interesting time to be in legal tech. Thank you for asking.
When this project got started, "VS code for transactional lawyers" was the target. We pretty well have that on offer at this point, but it sits in a weird spot making it harder to sell than it would be in, say, 2024. Right now, "AI forward" lawyers are spinning out of law firms in droves to start "AI native" firms backed for example by YC. They're so comfortable with Claude that they for the large part bypass a need for Tritium (or at least they think they do ;). OTOH, large law firms are inundated with legal tech products right now and have a hard time even understanding how an IDE benefits their lawyers. We're also trying to stay away from VC funding (other than from a certain awesome one ;), so we're missing a key signal for enterprise buyers. As I mentioned above, it's super hard to even set up a hands on demo because we have to get the desktop app installed on their infrastructure. But I'm shocked to learn that Googlers are happy to work in a browser, and distributing Tritium via browser is trivial, so we're going to 180 on that right here and now.
That all said, we eliminated the "free tier" as advised back in the Show HN thread, and we've managed to find a very small market in individual users. We're also finding some opportunities with the AI natives using an "unreal engine for legal tech" model that makes Tritium source available and handles the boring editor-related parts of their innovation.
I should probably do a post on this, but there's actually a topic we're working on that perhaps the HN audience will find even more interesting... coming soon!
[edit: I realized that I haven't responded to your question re: other markets, but accidentally did with the hint. We have some ideas.]
2 replies →
The main thing holding most people back from web-based IDEs is restricted filesystem and tools integrations, but cloud office suites are extremely popular. Google has excellent infrastructure for distributed build and test cycles built into Cider to go along with the entirely remote version control system.
Best of luck on your web-based demos! Dropping people into a working dummy environment with a few tutorial prompts should really help conversions.
> 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?
3 replies →
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."
I dunno, there's certainly a lot of monkey knife fight deprecations, but there's a lot that are handled pretty well.
If we're talking about the source side of things, p4->piper/citc was done well. cs (get) -> grimoire was done well. I'd like to think we did a pretty good job of grokv2-> Kythe, though we did drop a few clients of grokv2 who were wayyyyyyy the fuck up xkcd/1172 creek (we did try to help them in the right direction, like offloading onto direct blaze depserver queries).
I guess those are all close in the org to cider, so maybe that's just how dev infra deprecations used to go.
haha, that's a great way to put it! And I get the overall gist of it, but why monkeys? :)
6 replies →
fucking lol, that is how it usually goes with deprecation.
Initially I had thought so too. But later I realized that it’s quite easy to do so when you force-deprecate the old product. There was no real choice, the old IDE simply stopped working after a certain cutoff date. Adoption metrics felt forced and pushed, but were presented as if users were actively and willingly choosing the newer IDE.
I feel like core dev team learned a lot about actually enabling a web based ide for line 100k engineers across the globe for a gazillion line mono repo. ciderv is really just a skin for the amazing infra. Which is also why I think there was less resistance to the change
It would be nice if they extended their external services the same behavior…
Xoogler 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.
Yep, I made my own! (Xoogler 2017-2023) this is my noogler IDE story, one of my favorite, proudest hacks!
I developed a fork of the IntelliJ IDE on my second week at google out of raw frustration over latency. At the time I was commuting 2-3hrs/day SF<>MTV on the gBus.
Connectivity on the bus wasn't optimal, and there was high latency. Cider didn't have deep integration, and wasn't able to let me explore and understand the internal APIs effectively. I found it easier to enter a debug session within Intellij then 'vibe' and explore the internal apis via superComplicatedObject.ini<tab>.
Faced with an alien architecture + ADHD-unfriendly flow-crushing remote desktop latency -- and the lack of discoverability, I started hacking at it and without any knowledge of the system and architecture. Just tracing Intellij execution, subprocesses and network calls.
I was able to hack together a prototype in a few days that allowed me to run IntelliJ on my Mac, while the heavy bits ran on my corp desktop. The system would mount the remote filesystem over sshfs, would monitor and patch network connections and setup transparent shim binaries. Half of Intellij was running on the Mac (the front end) and the other half ran on Linux. Intellij didn't "know" that that it was running on a mac. This was initially implemented in a ~250 line shell script that patched everything.
It was called MDProxy[1] and ended getting adopted and supported during COVID as more development went remote. This became a source of many peer bonuses and spot bonuses. circa 2017* remote coding options at the time:
[1] https://github.com/bazelbuild/intellij/blob/6b8f03c21172033a...
Dude I was there 2019-2022 and mdproxy was a huge win when I realized I could work while traveling. I remember following some incantations on someone’s personal page to get it running. Then covid happened and I was ahead of everyone for a few weeks because I already had been doing real work on my laptop. Thanks!
> flow-crushing remote desktop latency
Yeah, I was working out of the Sydney office. Almost everything was incredibly slow due to that latency, not just chromoting but also just accessing most sites through beyondcorp.
oh wow! that sounds awesome! (I guess I left around the time you were starting)! I was based in LAX (so no G-Buses for us, but I had to visit MTV often - like once twice a month, and enjoyed getting on one of them)). Kudos!
I’m surprised you find ssh+vi having medium typing latency. I have ssh’ed to either my desktop to (later) my cloudtop and latency has always been great. The ssh latency is good enough that I can run X forwarding to launch graphical instances of emacs and gvim. The latency was basically unnoticeable.
Later I rented a vacation home in South Lake Tahoe and worked remotely. It was only then that I realized it had terrible latency.
1 reply →
"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).
There is in fact a version of cider that does work for folks working outside of google3, such as android. It's not as seamless, but it has been getting better and tries to recreate the google3 experience.
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 running in the cloud but at that point you might as well run that locally and cut out all the issues introduced by networking.
(current Googler)
For what it's worth we still use Android Studio as well internally, it is better and faster for doing specific UI stuff because of the tooling and visualization.
On the flip side the Google monorepo is a pretty cool thing and you get used to switching between projects and languages within the same commit chain pretty often. This is part of the reason the cloud IDE is so popular because it's one common editor across many languages compared to language specialized IDEs like Android Studio.
Regarding networking, it's not a big issue day to day. The infra team does a really great job building tools that do efficient caching and integrate well over the network.
"Android" here refers to the Android operating system, which (like Chrome) has its own separate development stack. Most of Google's Android apps are developed using the main google3 stack described in the post, or at least were when I was there.
> For anything with native UIs, I suppose you could "remote desktop" into an app or a simulator running in the cloud
This does exist. The network isn't the main problem. The Emulator has to run under nested KVM. That + graphics rendering on the CPU makes it not so responsive. It's useable enough in many cases though.
iOS apps at google are developed via ciderv that had a connection to your local mac, and it's amazing. All code editing is "online" and builds are cached, but simulator runs on your local machine. I'm convinced the apple dev env at google is like 100x better than apple's
> 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.
1 reply →
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.
1 reply →
I 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?
I have never worked at Facebook but I have always thought of Critique as the best code review tool I’ve used. It’s way better than GitHub. A few things I miss: (1) it has convenient and intuitive pure-keyboard navigation; (2) you can reply to code review comments in a pending form and then publish them after you update your code, because in the common case you address code review comments by updating the code; (3) until recently GitHub wouldn’t allow you to comment on lines far away from the changed lines but Critique has always allowed it, because obviously this is an important use case when the reviewer needs to point out the changed code affects some other regions; (4) it had support for diffbase so it displayed stacked CLs fine.
Critique had had a redesign between end of 2019 / start of 2020. I didn’t recall adding any significant features but it merely modernized the UI. So did Buganizer and Code Search. So if you thought the UI was clunky well it had been addressed.
Buganizer UI: https://issuetracker.google.com/issues?q=Android%2F
Code Search UI: https://source.chromium.org/chromium/chromium/src
Unfortunately I wasn’t able to find a public instance of Critique.
Oh yeah, not to mention the drag and drop GUI mercurial client in the IDE. I still haven’t seen anything as good on the outside.
Regular engineers could use stacked diffs proficiently and regularly, without it being seen as a super advanced 10x engineer power user thing.
I left Google end of 2022, but we already had the mentioned new version of Cider based on VS Code for a few years before that. It's possible FB did it first, but I don't think Google was far behind at all. I'm fairly certain there was the new VSCode based Cider by early 2020. Certainly was by end of 2020 and entirely common by the time I left.
(I didn't get to use it much because I worked on embedded stuff that was on the Chromium stack and in git, not in Google3)
Buganizer (v1 and v2) was delightfully primitive and simple. That was the point. PMs couldn't play games with it.
There is enough flow of engineers between the two companies that many of the things Facebook has done better have been copied by Google. I think in many ways it goes both ways.
I jumped from Google to Meta in 2022 (Worst. Timing. Ever.) and by that time Google's IDE had pretty much caught up. Android app development at Meta was super painful because of the repo size. My good morning routine was to kick off a 40 minute sync, and then get coffee and wander the building while I waited.
And the instant start cloud dev servers complete with shareable full stack preview links! Chefs kiss
Was 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.
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.
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 their unusual situation, but it's worth keeping in mind that their approach probably isn't ideal in ~most modern dev scenarios.
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.
Was this due to security and/or technical reasons?
It was a security policy. It used to be common to have local checkouts on workstations, but now everything is in the cloud.
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 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.
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.
5 replies →
Maybe, but I feel like an article I’ve read many, many times is “we hired one or more Xooglers for our startup and this turned out to be a catastrophe because they insisted on trying to bring blaze/bazel with them and it nearly destroyed the company.” It’s always bazel specifically in these articles, never any of the other internal Google stuff like Spanner.
3 replies →
Well bazel is a joy to use as a user but it’s painful to set up.
This is the other way people work at Google. You have a Vm and then connect IDE of choice to it via SSH. But honestly it’s a lot more effort that just using Coder
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 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.
Visibility doesn't always get you value though. See the many companies that unify their ticketing to something like Jira, and end up running reports on in. The actual accuracy of the aggregates is rarely great, and instead leads to people doing "jira optimization" to make reports look good.
I once worked at a place where VPs were looking at sprint burndown charts, and asked what happened if the line didn't look a lot like the line expected by JIRA. The telemetry is therefore often a curse, as any metric becomes a target. How many companies today have KPIs about having automated code reviews, which are then ignored by the devs, because said reviews are just wrong on almost everything?
The learnings of Seeing Like A State don't apply just to governments.
You have to be very careful in management to not create perverse incentives. I like to use change control processes as an example. In theory, a super strict change process for every single change is great, because it'll ensure everything gets reviewed thoroughly. In practice, that leads to people flouting the change process as much as they think they can possibly get away with, because it becomes a serious impediment to getting work done. A more moderate change process would have higher compliance, and actually lead to more oversight, than a super strict one.
> 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.
I 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
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 projects than any other company? They are still largely an ads company, no?
> 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?
They have a ton of other software in 2026. And they have a pretty diverse (and diversifying) income stream today. Like 30-40% from non-ads.
Is it worth it? That’s for them to say, but they can ramp up cloud services at scale pretty fast as a core competency.
I mean, ads is 73% of revenue. Of the rest, ~60% is Cloud, ~35% is hardware and subscriptions and app store fees.
So, sure, lots of spots for software there. But still nothing that would make me think of them as a software company. Or, worse, a lot of software that I don't have a strongly favorable view on. :D
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.
Totally.
GCP makes more revenue than Oracle, which is in the 96th spot. Also YouTube was 2x Paramount revenue in 2025.
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 complaints about AWS back in the day. It wasn't a lack of ML offering in AWS that made Amazon Photos less useful than Google's photo offering. Despite what some internal folks would say.
2 replies →
> 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?
Do they have more success in software products than other companies, though? Most of the software many of us know from them, were acquisitions. They still do heavy acquisitions. Notable that they have double the acquisitions of Amazon. They are on par with IBM. A colossal amount of money spent to make things happen.
So, again, are they that much more successful at software than other companies? They have more hilarious flops than any other company.
Don't get me wrong. I still use some of the stuff. I don't hate them. I don't even think they are particularly bad at things. I just don't think they are any more successful than other software companies. Specifically at the software side of it.
12 replies →
The Acquired podcasts on Google are a solid background.
https://www.acquired.fm/episodes/google
Google is an ads company with a large amount of infrastructure to back it up.
Sure, the money is mostly in ads, but serving searches, AI, youtube, and all the rest at the scale Google does it requires a technical tour-de-force. Does Google do it better than everyone? Absolutely not. But it does it better than many.
Certainly it isn't the _only_ way to do it--other companies also manage to do it. But not all that many at the same scale. It's an existence proof that you can.
Most of what they do really really well, though, is accomplished by massive amounts of spending. That isn't a knock on it.
Consider that they spend more on trying to build up and support this central IDE than most companies dream of losing in productivity to not having this.
There are things people do in Borg that when ported to our own public cloud kills entire regions. Sure you get limited choice but things work at global scale without thought
The catch is that you need to build good software so people use it so that you can show ads
The caveat to that, though, is that "good" is another term that you can frame however you want.
Luckily, they still support the text editor + CLI tools workflow so I can still use Emacs effectively.
The 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.
As far as I remember, this "IDE in cr/" explanation was found afterwards.
I use mondrian/ instead of cr/
The thing I most love about Cider-V is that moving between it and (often remote) VSCode when working outside google3 becomes mostly painless.
I 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.
This is the way.
But the downside is that you do get the Cider team constantly messaging and asking for reasons you won't switch. I gave feedback that their Vim bindings were broken (it would sometimes fail on holding down directional hjkl for no reason) but I'm not sure if they've fixed it since I left in 2023.
Cider is good for writing g3docs though.
I can't say for sure because I never used it, but neovim is the jam.
same! how do you deal with cloudtop latency though? sometimes my neovim is very slow and laggy because of the remote connection / network file system
Cloudtop to run builds, g4 commands, etc., and srcfs / srcfsn to actually write code. (caveat: I have never used neovim, so I don't know if that is different).
I use a workstation specifically to improve latency. Needed to get approval at some point to get a refresh though.
2 replies →
Spin up one in the US central region instead of an instance near your satellite office. The bottleneck is usually not your shell connection to the instance but the connections from the instance to all the infrastructure that's mainly based in the US.
Mosh instead of ssh. Works well enough for as long as it works.
Road warrior even supports it.
But i keep going back to regular ssh or shpool with roadwarrior.
Ever tried SSH'ing via "Mosh"? https://mosh.org
I have a (Google-issued) desktop in the same city I live in, so the latency is not so bad.
1 reply →
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.
> and while it was so ahead of its time, it didn't get enough of an uptake to satisfy... certain executives in engineering.
There's more to the story than just that. Jeff might remember the particulars. I don't want to badmouth anyone on second hand information.
There was also the code search, uh, I forgot the name "quick change", I believe?
Very handy for seeing a problem, quickly solving it (sending out a CL) marking it autosubmit and just moving on.
I assume quick change became critique?
6 replies →
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.
I'd love for more screenshots should anyone have and can share. I still don't get a great picture of how it's running in the browser and I find UI choices fascinating. But I imagine I'd need an NDA to see the settings/options :')
2 replies →
OP is an ex-Googler
Xoogler. We have slack and everything!
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 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.
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 costs of engineers are very different. I'm really unsure why you would think otherwise.
Unlike others, Google is also remarkably good at quantifying the actual value something provides in developer productivity/etc. Most engineers handwave this tremendously. Google has an amazing amount of telemetry. So i laugh when you talk about "the leverage over developer productivity" because the vast majority of companies i've worked at or talked with have almost no useful idea about their developer productivity (IE can't even account for the majority of their developers time at work), or how to invest effectively to do something about it. They can often account for <30% of time developers are spending at work, etc.
As for perspectives - there is plenty of sentinment and other data. Cider is overall one of the top 5 most loved tools at Google, and had well over 90% developer satisfaction IIRC.
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.
3 replies →
Cider-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.
Do Java engineer at Google not use IntelliJ?
Not anymore they don't (usual caveats apply: no longer work there; big company so YMMV). It was an option for a while, but getting it to work with the remote filesystems for the monorepo was a bit annoying (e.g. you'd create a new project in IDEA where you'd have to pick what parts of the monorepo you wanted to have in there, but it all happened up front).
> 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.
Yes, there were over time, multiple teams working on intellij plugins to support google3 before it all got relatively merged.
You are talking, i believe, about the support for blaze builds in intellij, which was fairly early on, as you point out.
I suspect Laurent is remembering some of the google3 mobile/android efforts, which were much later.
This is just on the "java" side, too. There were other plugins being built that were fairly specific to google3 support.
Nice to see you Brian!
Blaze was started late 2005 or early 2006. Eclipse+IntelliJ was also at that time.
The IntelliJ blaze plugin was already started and out when I joined in 2007. My first job was to keep it from being rewritten yet another time, get teams to use it, and also keep it from being cancelled.
I'm not sure about the dates. At some point (2014?), the use of IntelliJ was discouraged in favor of Eclipse. One year later or so, the decision was reversed and the effort focused on IntelliJ (and Eclipse were considered deprecated).
IntelliJ was unsupported ("community supported") when I joined in the summer of 2015. I built a new protobuf editor plugin during that period as a side project, mostly for myself, which suddenly became used by thousands of Googlers when IntelliJ became the supported IDE again in ~2016?
I eventually handed it over to JetBrains and I think it ships by default with IntelliJ now.
Was there never a detour via Eclipse Theia? I thought it might have had some traction internally, since Cloud Shell is based on it.
2 replies →
Going 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.
I 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.
While 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.
I 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.
From the article: “ Cider was a light client that opened much faster than traditional IDEs. All the magic happened on a backend that indexes the entire codebase, so that all the data was ready whenever someone opened the webpage. ”
Sounds like all other editors were slow compared to Cider.
OK, this was probable me telling other people I have never worked in a large repo without telling other people that...
7 replies →
It's not bad, but I also don't see the point. It always felt more cumbersome than using Vim, even laggy sometimes despite having a fast MBP.
I'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.
The 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?
If you are very into agentic coding then in 2026 you're using Antigravity. But if you are less into it Cider-V has a slightly less powerful (e.g. no web browser harness, no multi-agent parallelism) version that is backed by the same implementation. Since both are built on VSCode this is ~ trivial.
In my experience, antigravity IDE is much less seemless compared to Cider-V. I completely moved to using web-based antigravity for the agent and using cider-v to make manual changes and viewing code.
Antigravity isn’t supported internally so it’s not an issue.
There is a similar internal product but the agentic part is shared between that and Cider.
Initially 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.
Everything turns into the thing it was set out to replace.
Something 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.
100% up-to-date VSCode is still pretty trashy, IMO. It's a mixed bag of plugins without cohesion, no awareness of code other than what that mixed bag attempts to provide (poorly). It is and always has been little more than a progressively more complicated mobius loop of autocompletion-oriented UI experimentation.
Ah, I feel so much better now. ;)
VSCode never made it past the first 10% of what Eclipse did (does). VSCode did succeed at being something for everybody, available everywhere.
Do you have an example of what eclipse can do that VScode can't?
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?
I 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.
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 that machine. There is a huge, absolutely amazing distributed build system that everyone uses for everything. (Again, Android and Chromium are different.)
So you don't really need a powerful local machine. I held out for a long time--there were a lot of growing pains in the early days. But eventually it got really, really good.
> You aren't even allowed to keep the source code on your local disk
How is this enforced?
2 replies →
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.
5 replies →
I miss my Dragonfly I am a big Linux proponent but that Chromebook had me convinced about the platform. Amazing integration.
I can understand Android (including the Linux kernel) being "too big" and "too separate" to go into Google3, but why Chromium? When it was forked from KHTML/WebKit it was probably not that big compared to the rest of Google's codebase.
3 replies →
What is Google3?
9 replies →
For most of my time here I used exclusively Chrome OS, and switched to it for personal use as well. My daily driver for years was a bright red Samsung Chromebook Galaxy (the first gen with the actual metal case). Literally none of my work is local, and it could run Secure Shell, Cider-V, and Docs as installed PWAs with their own taskbar items, etc. It was glorious.
When it finally failed in the most annoying way possible (the touch screen, which I do not use, started creating phantom clicks in the upper right corner of the display) I went looking for another Chromebook that was light, powerful, and well-built. Finding none, I now use MacBook Air and weep for the time I lose every time it needs an OS update.
Ive had that issue with touchscreens before and was able to disable the driver for it. Linux so not sure if possible or how on a chromebook but an option.
How common? I'd wager most people still use a mac, followed second, but far by regular goobuntu laptops. Chromebooks goes 3rd because Windows is practically banned.
Ubuntu/gLinux laptops have been getting phased out for a while. It's 1. Mac 2. Chromebook 3. gLinux probably
> Windows is practically banned.
FWIW I don't think this is accurate (was kinda true in the 2010s?). I wouldn't be surprised if it's almost easier to get windows laptop than linux one now.
When I joined, I started with a MacBook and lost it within three months :(
Afterwards I was issued a 12" Pixelbook and it was surprisingly much more usable than I had expected! I could ssh into a Linux box for running builds and tests. Cider worked perfectly. It was snappy enough to serve as a thin client even on a 4K screen.
Chromebooks are pretty much only good as thin clients, so much so that when I have the money I plan on building a powerful rackmount workstation and connecting to it via chromebook/box
I do most of my development on a MacBook air and a Chromebook. The ~only thing I do from my local machine is ssh into a beefy workstation and use chrome.
Since it's mostly browser tabs, as long as you have ample memory (eg 16gb) it's good enough.
From what I'd heard contractors get issued as little as a Pixel tab and dock? Everything else is in the cloud (either gLinux desktops or cloud shells) AFAIK.
Java 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.
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 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.
[1] https://antigravity.google/
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.
How many new googlers use vim or emacs do you think? I can imagine at least a small amount of new vim people since vim will always be popular, but I would love to know if more than a handful of new googlers a year use emacs
I've switched to emacs and I no longer use IDEs. This is because I do all my edits, as a personal policy, via LLM. I mostly use emacs for magit (I work on a git-on-borg repo).
I joined gdm recently, and previously used (neo)vim exclusively. Begrudgingly Cider-V is very, very good. It might be possible to get by without it, but the system is so locked down you’re going to make a lot of sacrifices. (very few authorised extensions, codebase is so large it’s going to break whatever tools your used to using anyway, no git)
I’m well thinking I may as well trade my brick of an m5 pro for a 13” chromebook, it’s a strange time.
6 replies →
Famously Jeff Dean uses emacs. Emacs integration to internal systems (source code, code search, LSP, build, etc) was super solid when I was there ~2020.
There is an internal website that tracks statistics of tool use, where “tool” is defined liberally and includes emacs. It would be tracked if you just (require 'google) somewhere in your initialization code.
I can't check when Cider got started. I was probably wrong (it wasn't much used in my circles at that time), I'll update the post.
Is Antigravity a Cider-V fork?
I don't think so, I think they forked VS Code directly or possibly forked Windsurf which forked VS Code. Hence the turf war and internal controversy; a lot of the effort on Cider-V got dropped on the floor, right at the height of Cider-V's popularity when they were getting large amounts of features.
Duckie does still exist, and is probably one of the most used (and useful) AI tools at Google. Yes, it's just a Gemini wrapper with access to all the internal documentation. I wasn't doing daily development when I left so I don't know if it ever got into Cider-V.
1 reply →
Okay, but what about the corgies?
No. Antigravity is the public version of jetski which is a VScode fork made by the windsurf team.
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.
> Over time, engineers realize that Code Search is more important than their IDE.
You nailed it.
One particularly hard problem Google faced w.r.t. IDE integration was the intersection of thousands of RPCs defined by protobuf declarations => generated protobuf code in 10 different languages being dong transparently by blaze + not checking in generated code => where does the IDE based indexing find the generated source files, and then tie that back to the original .proto file declaring the RPC declaration. Blaze had the information available through a query, but needed ways for the user (the IDE) to optimize the query plan so that it could deliver just the proto related dependencies with sub-second response time to keep the human users happy.
Once you found the .proto file that defined your data they could leverage the the monorepo and search over it. Let's say I am a Java programmer working on a server endpoint and want to change the format of some data I am stuffing into a protobuf. I could find the original declaration, and then find all the instances of objective-C code that our iOS apps were using to consume it. Trivially easy with the combination of global code search and a global dependency graph.
Caveat: Code search and a monorepo let you do some amazing things. But there is a LOT of cost which Googler's tend to nostalgically gloss over. piper, citc, kyte, critique, and depserver* represent (wet finger in the wind guess) probably $100M of development effort.
Context: Googler from 2007-2025, worked on API serving infrastructue, desktop apps (yes, we checked out source code to windows laptops), blaze/bazel, and a few others. I've seen all the developer tooling problems.
*depserver is a essentially a service that holds the entire blaze dependency graph every file up to every buildable object across the code space. That drives the automatic testing infrastructure.
Yeah I just use vim and jetski CLI, way faster than dealing with any of these IDEs
From what I've heard rumor-wise, everyone has abandoned the web UI editors and are now using (or being told very loudly by management to use) Antigravity exclusively for everything.
Is the V in Cider-V the Roman numeral 5 or V like in Visual?
V as in VSCode.
so, visual :P
I wonder if the IDE will eventually die, and be replaced by something fundamentally different, like Claude Code Desktop, Codex Desktop, Lanes.sh, or Factory.
As a noogler, I feel like I missed all the cool toys. And now I'm stuck with whatever they've acquired.
Been using Cider for two years now. Early on I struggled, trying to use IntelliJ, and even tried the thin client version — but both are basically in maintenance mode. Cider is the de facto standard. It really is the best IDE in terms of integration with internal tools, but it also inherits Google internal tooling’s general disregard for UX quality and aesthetics.
The aesthetics are literally vs code though .....
xoogler from 2005 to 2018. People in developer tools always wanted a mandate to use their tools when their tools didn't gain enough users.
Another 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.
I'd rather have a remote hosted devcontainer and a local IDE. No fiddling, settings pushed on the container (same with plugins to use etc).
The keybindings with the web ide's always are a drag to me, actually the lack of good keybindings.
> There's more history than this
LOL. Understatement of the year, Laurent. :-)
Real IDEs are built by Jetbrains.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]