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.
[deleted]
A History of IDEs at Google
311–320 of 333 posts
Re: A History of IDEs at Google
#312I 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.
[deleted]
Re: A History of IDEs at Google
#313I 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.
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.
Re: A History of IDEs at Google
#314When I left Google in the mid 2010s, there were a couple unusual constraints: 1. They had the majority of their code in a vast++ monorepo. 2. There was a policy that forbade having code from this monorepo on your laptop. Most companies and projects have orders of magnitude less code, and don't restrict where that code can be stored. It's interesting to learn about Cider and the other things Google built to address th…
> There was a policy that forbade having code from this monorepo on your laptop. Was this due to security and/or technical reasons?
It was a security policy. It used to be common to have local checkouts on workstations, but now everything is in the cloud.
Re: A History of IDEs at Google
#315Earlier quoted context omitted.
Do you mean local checkouts? There's a similar workflow with at least mercurial? Dunno about jujutsu.
You don't really need it anymore - CitC let you do views (mapping just part of the monorepo into your filesystem via FUSE) since about 2013, and then that functionality just got built into Piper. When I returned in 2020 you'd have a file at the top of your source tree that included all the relevant file mappings as well as any Blaze flags needed to build the project, and you could just point your IDE at that and it'd…
+1. CitC and it's relationship to version control (perforce/piper) is central to all development.
Let's say there were 100M file in the monorepo (an underestimate). You obviously never want to do a git clone of that. But what if clone and checkout were free? That's what CITC did. Creating a new workspace took less than 1 second and got you a FUSE filesystem that looked like it had everything in the repo. But nothing was actually downloaded until you opened files. And your local changes were also stored in the service. And this was available to the CI machines. See where I am going. CI did not have to clone the repo and apply your branch. CI just had your changes available. If you were just testing your 10 files there was no cost to having 100M other source files that were unrelated to your project.
This solves many problems that git worktrees attempt to address, but 10 years earlier, at less local disk cost, and more performant. I miss that.
Re: A History of IDEs at Google
#316Earlier quoted context omitted.
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 cost…
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 hir…
I mean, everything's my fault - it was overall my org, so it doesn't matter who did it in the org. That's the job :)
As for Eclipse, you are correct that at one time it had tons of users, but eclipse was dying very quickly, with no signs or possibility of recovery, well before any decision was made to intellij. People were already moving. So not sure what you are remembering there. Eclipse was dead no matter what we did. There were people that loved it (sounds like you are one of them), but at the point of deprecation, death was already clear.
Additionally, given the Android team's desire to use IntelliJ, mobile first, and all that jazz, we were going to be forced to support IntelliJ as a first class citizen no matter what.
Eclipse literally made no sense to keep going with given all that.
Re: A History of IDEs at Google
#317Xoogler 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 understan…
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!
Re: A History of IDEs at Google
#318This 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 toolin…
> 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.
Re: A History of IDEs at Google
#319> There's more history than this
LOL. Understatement of the year, Laurent. :-)
Re: A History of IDEs at Google
#320Earlier quoted context omitted.
There's no reason to pull the entire repo just to build one project. Do you pull all of GitHub to your disk?
From the user interface perspective though, it does essentially look like you've pulled all of google3 into your disk.
But is it a local disk? The post above says that one uses Chrome Remote Desktop.