Do Java engineer at Google not use IntelliJ?
A History of IDEs at Google
301–310 of 333 posts
Re: A History of IDEs at Google
#302Before cider there was Brightly. My recollection was that it was developed by a team in Atlanta and got cancelled before it reached general availability. People were pissed at the time (ex. "cancelling brightly considered harmful"). That died down when Cider delivered on what Brightly had promised. The days of using Eclipse were particularly bleak. These days I use Antigravity for the overwhelming majority of my work…
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 terrifi…
There's more to the story than just that. Jeff might remember the particulars. I don't want to badmouth anyone on second hand information.
Re: A History of IDEs at Google
#303Earlier quoted context omitted.
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...
How is this so much faster than browsing my tiny little repo on Github? What is Github doing so wrong??
They open sourced the tool to do it- https://kythe.io - but I think it would be a pain to make it work for anything like GitHub that supports arbitrary languages and build systems with untrusted code
Re: A History of IDEs at Google
#304Earlier 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...
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
Fun read seeing even with all the tools in the world there is not enough soul or will to fix a very minor regression made by human error of judgement and other companies just accept that like their lives depend on it.
Good thing after reading the above article came to know its possible to use this https://github.com/ungoogled-software/ungoogled-chromium has a flag to store old history.
Re: A History of IDEs at Google
#305I 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…
Critique had had a redesign between end of 2019 / start of 2020. I didn’t recall adding any significant features but it merely modernized the UI. So did Buganizer and Code Search. So if you thought the UI was clunky well it had been addressed.
Buganizer UI: https://issuetracker.google.com/issues?q=Android%2F
Code Search UI: https://source.chromium.org/chromium/chromium/src
Unfortunately I wasn’t able to find a public instance of Critique.
Re: A History of IDEs at Google
#306Earlier quoted context omitted.
Yeah I've considered that as well. Was loving having everything in the same ecosystem and have been pleased with the Gemini 3.1 models. I still think this is a blip and Google will come around. It doesn't make any sense.
You're not missing much -- Claude is a better model for coding. That's what basically everyone at Google DeepMind uses and what I expect most other Googlers would choose to use IF they had access: https://www.businessinsider.com/google-deepmind-ai-tool-divi...
https://www.oreilly.com/radar/dont-automate-your-moat-matchi...
Re: A History of IDEs at Google
#307Re: A History of IDEs at Google
#308Earlier 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...
Re: A History of IDEs at Google
#309This 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…
Re: A History of IDEs at Google
#310I 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.
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.