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

91–100 of 333 posts

Re: A History of IDEs at Google

#91

Post by Arainach »

lozenge wrote: post #87
compiler-guy wrote: post #6

Earlier quoted context omitted.

Very little development in Google3 happens locally. You aren't even allowed to keep the source code on your local disk, and this is true no matter what OS it runs. (Android and Chromium are different though.) You have access to an extremely powerful remote workstation that from a UI perspective functions almost identically to a local workstation, via Chrome Remote Desktop. Plus, no one builds things locally, even on…

I can understand Android (including the Linux kernel) being "too big" and "too separate" to go into Google3, but why Chromium? When it was forked from KHTML/WebKit it was probably not that big compared to the rest of Google's codebase.

Chromium is open source. As such it needs to be hosted via a publicly accessible stack (Git/Gerrit) so that external contributors can use it.

Size has nothing to do with it.

Re: A History of IDEs at Google

#92

Post by Andrex »

mcoliver wrote: post #57

Meanwhile Google acquired windsurf, released antigravity, and recently handicapped it for Google business workspace users by removing the AI Ultra plan for workspace. So the only real way to use antigravity is either being a Google employee or using a personal account and AI Ultra. https://knowledge.workspace.google.com/admin/gemini/ai-ultra...

Anyone care to speculate what the internal reasoning is?

Re: A History of IDEs at Google

#93

Post by Keyframe »

Andrex wrote: post #92
mcoliver wrote: post #57

Meanwhile Google acquired windsurf, released antigravity, and recently handicapped it for Google business workspace users by removing the AI Ultra plan for workspace. So the only real way to use antigravity is either being a Google employee or using a personal account and AI Ultra. https://knowledge.workspace.google.com/admin/gemini/ai-ultra...

Anyone care to speculate what the internal reasoning is?

Google has a rich history of product mismanagement. It would be a shame and legacy ruined if it were to change.

Re: A History of IDEs at Google

#94

Post by zhengyi13 »

derriz wrote: post #59
barrkel wrote: post #35

Earlier quoted context omitted.

You want bazel. Once you've internalized the bazel (blaze) system, you want all builds and tests to work that way.

How do you internalize it? Our bazel system is full of custom skylark code so understanding the build means effectively reading a bunch of ad-hoc code written with varying degrees of competence and with confusing dependencies. I’m kinda ashamed I don’t have a deep understanding of a tool I use daily - but every time I try reading the documentation I quickly give up.

Probably not in the way that you might mean it, but for me (Xoogler, 2010 - 2023) internalizing bazel means:

"Hey, where's your tool's code in $MONOREPO?" ""

Cool:

    g4d my-citc-client # moral equivalent to `cd ~/repos/stuff`
    blaze run path/to/stuff:target
... and you get a running version of whatever $stuff is, immediately built from head, quickly - no matter the set of dependencies, or which language they were built in. I can just try your thing out immediately with a common interface for all the builds, and I don't need to understand the build at all, unless or until I do, and then OK, absolutely every single build is always expressed in exactly the same way, same idioms, same patterns...

Re: A History of IDEs at Google

#95

Post by hnthrowaway0315 »

FrojoS wrote: post #90
hnthrowaway0315 wrote: post #83

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

From the article: “ Cider was a light client that opened much faster than traditional IDEs. All the magic happened on a backend that indexes the entire codebase, so that all the data was ready whenever someone opened the webpage. ” Sounds like all other editors were slow compared to Cider.

OK, this was probable me telling other people I have never worked in a large repo without telling other people that...

Re: A History of IDEs at Google

#96

Post by mark_l_watson »

Andrex wrote: post #92
mcoliver wrote: post #57

Meanwhile Google acquired windsurf, released antigravity, and recently handicapped it for Google business workspace users by removing the AI Ultra plan for workspace. So the only real way to use antigravity is either being a Google employee or using a personal account and AI Ultra. https://knowledge.workspace.google.com/admin/gemini/ai-ultra...

Anyone care to speculate what the internal reasoning is?

I can guess: I am 3 weeks into a 4 week Ultra subscription and the amount of Claude Opus and Gemini Pro tokens that they give you on the subscription is very generous - I feel like I have been gorging on tokens, tidying up 25 years of my open source projects. When my one month subscription runs out I will miss it.

Re: A History of IDEs at Google

#97

Post by nimchimpsky »

barbolo wrote: post #82
mcoliver wrote: post #57

Meanwhile Google acquired windsurf, released antigravity, and recently handicapped it for Google business workspace users by removing the AI Ultra plan for workspace. So the only real way to use antigravity is either being a Google employee or using a personal account and AI Ultra. https://knowledge.workspace.google.com/admin/gemini/ai-ultra...

It was a sad surprise last week when we tried to upgrade the workspace AI plan for some of our team members to Ultra and it was gone. We're moving to Claude/Codex.

[dead]

Re: A History of IDEs at Google

#98

Post by AJRF »

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…

Cool - thank you for answering

Re: A History of IDEs at Google

#99

Post by DannyBee »

w10-1 wrote: post #34

I had to laugh we he said it took a dozen people a couple years. That's a terribly small investment relative to the leverage over developer productivity, and pales in comparison to what eBay, IBM et al spent in similar large but specialized developer populations for integrated tooling. I'd like to hear the perspective of the developer/user; the IDE provider has some incentive to take credit and imply high utilization…

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 costs of engineers are very different. I'm really unsure why you would think otherwise.

Unlike others, Google is also remarkably good at quantifying the actual value something provides in developer productivity/etc. Most engineers handwave this tremendously. Google has an amazing amount of telemetry. So i laugh when you talk about "the leverage over developer productivity" because the vast majority of companies i've worked at or talked with have almost no useful idea about their developer productivity (IE can't even account for the majority of their developers time at work), or how to invest effectively to do something about it. They can often account for As for perspectives - there is plenty of sentinment and other data. Cider is overall one of the top 5 most loved tools at Google, and had well over 90% developer satisfaction IIRC.

Re: A History of IDEs at Google

#100

Post by DannyBee »

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"
Post reply on HN