Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A History of IDEs at Google

laurent.le-brun.eu

Post reply on HN
Print view View original

321–330 of 333 posts

Re: A History of IDEs at Google

#321

Post by shaftway »

exclipy wrote: post #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 wa…

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.

Re: A History of IDEs at Google

#322

Post by shaftway »

barrkel wrote: post #246
Analemma_ wrote: post #228

Earlier quoted context omitted.

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.

I mean, bazel is great and I would use it when building a codebase from scratch, but the win from switching from one build system to another is, at best, some efficiency, and you need a lot of aggregate efficiency gains to pay for effort.

I was at Block and there was an interesting problem around this.

A number of Google engineers had come over, and they pushed for a way to structure the codebase where you had a ton of tiny build targets. I think a "jumbo" build target would have more than 10 files in it. Under Blaze / Bazel this would have been absolutely fine, but they were still using Gradle for their Android builds, and Gradle does not like that. Doing a build of anything meant Gradle had to initialize tens of thousands of projects. A naive engineer trying to build a single project would have to wait for about an hour for everything to be structured.

There was a big push to move everything to Bazel, and the backend and iOS teams moved over just fine, but there was someone on the Android build team who had come from Gradle, and knew a lot of techniques to cut the build time down. I remember there was a tool you would run that would examine the project structure and set up an ignorelist of projects so that Gradle wouldn't have to load projects you didn't care about.

All of the tricks were a bandaid technique at best, and eventually that engineer left the team, but the damage had been done, and migrating to Bazel was a non-starter.

Re: A History of IDEs at Google

#323

Post by jbstjohn »

VirusNewbie wrote: post #298
hanwenn wrote: post #260

Earlier quoted context omitted.

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

Most of the engineers making most of the tools being praised in this thread are in Germany, so I don't think that generalization quite holds.

Even if the best SWEs are better in the Bay area, there's also a lot more competition for them, so Google in Germany might be able to get top 1% there (and in neighboring countries) but Google in the Bay Area is probably having a tough time getting even top 10%.

Re: A History of IDEs at Google

#324

Post by jbstjohn »

randomCloud wrote: post #159
spwa4 wrote: post #154

Earlier quoted context omitted.

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?

No, Critique existed before the quick edit feature was added to Code Search.

While I think the quick edits were worthwhile, it became too much too support both it and Cider (and edits in Critique), so it was removed to streamline things. As Cider became better, I think it was an okay trade-off.

Re: A History of IDEs at Google

#325

Post by jbstjohn »

hcnews wrote: post #163
randomCloud wrote: post #159

Earlier quoted context omitted.

I assume quick change became critique?

There was a code reviewer starting with M before Critique iirc (Mondrian I wanna say?). The M code reviewer was completely written in Python iirc.

Yep, and written by Guido von Rossum, no less.

However, experience with it led to my sense that Python just doesn't scale (especially back then, without type annotations) past a certain size of program.

The Code Search team had been re-inventing its UI and changing a lot (changing its focus from external to internal), and had the inspiration to leverage what they'd done to create Critique. They sold Mountain View on it, and made history. Exciting times.

Re: A History of IDEs at Google

#326

Post by dmoy »

DannyBee wrote: post #100
phreeza wrote: post #38

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

Re: A History of IDEs at Google

#327

Post by neerajsi »

bsimpson wrote: post #50
AJRF wrote: post #11

Earlier quoted context omitted.

What is Google3?

It's a monorepo, which is a bunch of libraries (in this case, the code for most Google products) in a single repository. Those libraries can have dependencies on each other. One is a framework called Wiz, which renders the frontend for a bunch of Google web apps. You can imagine that the Wiz team might want to refactor an API, but not have to worry about different apps using different versions. In a monorepo, they ca…

How does release management work? Are there stable branches for deployed properties with a cheery pick approach for bug fixes? Are all products in google3 on a coordinated set of release trains?

Re: A History of IDEs at Google

#328

Post by VirusNewbie »

jbstjohn wrote: post #323
VirusNewbie wrote: post #298

Earlier quoted context omitted.

The problem is most SWEs in Germany are not as good as most SWEs in the Bay Area. :(

Most of the engineers making most of the tools being praised in this thread are in Germany, so I don't think that generalization quite holds. Even if the best SWEs are better in the Bay area, there's also a lot more competition for them, so Google in Germany might be able to get top 1% there (and in neighboring countries) but Google in the Bay Area is probably having a tough time getting even top 10%.

That's a good point, and why I'm happy to see remote offices pop up in many locations. The problem is the top .1% which can live anywhere, is often a poor representation of the depth of talent density.

Re: A History of IDEs at Google

#330

Post by knightabu »

MarkSweep wrote: post #183
materielle wrote: post #128

Earlier quoted context omitted.

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

Brings back lots of memories. The only way i used that tool was back when Chrome stopped forever history near about the year 2014-2015 and limited users to 90 days of history.

I was trying to wrap around my head like reading the comments trying how to put it back in. Wrong strategy without serious review does more of harm.

More than a decade of this fiasco Google Chrome should bring it back forever history, now they dont have an excuse for this, what i hear (google Chrome now downloads an offline LLM without considering data charges or space requirements in edge deployed server,etc.), and it will help users themselves as now most browsers except Firefox or Safari are Chromium-Based and they too inherited this shiny features with not-so obvious limitations.

The History bug in point - https://issues.chromium.org/issues/40358997

Post reply on HN