Live data from Hacker News

A History of IDEs at Google

laurent.le-brun.eu

181–190 of 333 posts

Re: A History of IDEs at Google

#181
post #179

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

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
[1] https://github.com/bazelbuild/intellij/blob/6b8f03c21172033a...

Re: A History of IDEs at Google

#182
post #62

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

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

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.

Re: A History of IDEs at Google

#183
post #40

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…

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

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

Re: A History of IDEs at Google

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

Re: A History of IDEs at Google

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

Re: A History of IDEs at Google

#188

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

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.

Re: A History of IDEs at Google

#189

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

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

Re: A History of IDEs at Google

#190

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

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.

Post reply on HN