Hacker News

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.

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.

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

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

There are mercurial and jujutsu frontends now.

I still have nightmares about eclipse sometimes.

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.

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.

Google employees can’t use antigravity. There is an internal version of it which has an agent which is shared between Cider and it.

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

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

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

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?

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

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

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

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.

    > There was a policy that forbade having code from this monorepo on your laptop.

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

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

And the instant start cloud dev servers complete with shareable full stack preview links! Chefs kiss

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.

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.

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

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

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.

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.

The catch is that you need to build good software so people use it so that you can show ads

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

As far as I remember, this "IDE in cr/" explanation was found afterwards.

I use mondrian/ instead of cr/

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.

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.

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.

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.

OP is an ex-Googler

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

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.

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.

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.

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.

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.

Since it's mostly browser tabs, as long as you have ample memory (eg 16gb) it's good enough.

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.

V as in VSCode.

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

Everything turns into the thing it was set out to replace.

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.

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.

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.