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...
In fact a lot of Google software projects have a public version of code search: https://cs.opensource.google/
How is this so much faster than browsing my tiny little repo on Github? What is Github doing so wrong??
Wow that is a lot faster and nicer than Github.
This is a good example of large companies wouldn't send someone across the street to pick up $1M off the ground. If Google actually released that and a repo to public, they could take Githubs throne. But a few $B business isn't worthit for them.
It's not that the $2B business isn't interesting, it's competing with GitHub would be a major undertaking and the opportunity cost of doing that is probably more than $2B.
> 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.
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.
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.
JetBrains has several niches it excels in. DataGrip is by far the most important tool in my toolbox, as it allows me to work with every database type imaginable in one place (Databricks, Postgres, MSSQL, Oracle, etc.).
What tools available to the public would you say is similar to this workflow?
Sourcegraph is the closest external thing I've found to Google's internal web tool for viewing code.
The startup I'm at (ersc.io) is working in this space (version control more than the IDE side of things), because, in my opinion, there just plain isn't any.
https://github.com/jhuangtw/xg2xg has a broader list
The only thing remotely close is a monorepo checkout ... with all the problems that come with that.
[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.
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 map in just what you need.
The history of Google's relationship to version control is even more interesting than editors - it went from CVS in 1998 to Perforce (P4) in 2000, then gcheckout and g4 in ~2006, then OverlayFS was invented in 2008, git5 came out in 2009, CitC obsoleted OverlayFS in ~2012, Piper built this all into the VCS in ~2013-2014, while I was gone from 2014-2020 apparently we got hg and jujutsu frameworks, and then when I got back in 2020 you'd just check out a .blazeproject from your IDE and everything would magically work. Many of these started as 20% projects (I used to have lunch with the guy who invented OverlayFS; interesting character and one of the best programmers I knew) and then got folded into the "official" way of doing things once grassroot adoption showed the execs that this was how people really wanted to work.
Haven't tried. But there are "IDEs" (Unity) that are really hostile to the idea that your project directory is not a fast local disk that they can both fill with garbage and use fsnotify on everything.
When I joined in 2016, it CitC would make it look (and still does) like you had the entire monorepo on your local filesystem on your machine.
Git5 would copy some directories but builds would still fallback to files from the monorepo if you didn't track them. It was convenient for me since I could just grep and do fuzzy matching from my editor. Now I have to do some extra work to avoid grepping the entire monorepo. LLMs sometimes still try to grep the entire repo lol.
Now, you could use a perforace, mercurial, or jj interface and it works fine.
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
That is not quite the right word. For Python, the headcount was moved from the Bay Area (the most expensive place in the world to hire software engineers) to Munich (the most expensive place in Germany to hire SWEs.), for cost saving reasons.
The problem is most SWEs in Germany are not as good as most SWEs in the Bay Area. :(
If you're the author of https://github.com/hanwen/go-fuse/ -- thank you :D
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.