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

141–150 of 333 posts

Re: A History of IDEs at Google

#141

Post by kccqzy »

tipsytoad wrote: post #68
mghackerlady wrote: post #27

Earlier quoted context omitted.

How many new googlers use vim or emacs do you think? I can imagine at least a small amount of new vim people since vim will always be popular, but I would love to know if more than a handful of new googlers a year use emacs

I joined gdm recently, and previously used (neo)vim exclusively. Begrudgingly Cider-V is very, very good. It might be possible to get by without it, but the system is so locked down you’re going to make a lot of sacrifices. (very few authorised extensions, codebase is so large it’s going to break whatever tools your used to using anyway, no git) I’m well thinking I may as well trade my brick of an m5 pro for a 13” ch…

When I was there all the cool people used mercurial. Git5 was creaky and didn’t work well but hg worked brilliantly. The cool people used hg to do stacked CLs so they were productive even when blocked by code review.

Fun fact: This particular version of hg with its extensions actually originated from Meta.

Re: A History of IDEs at Google

#142

Post by richardboegli »

materielle wrote: post #128
cletus wrote: 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…

What tools available to the public would you say is similar to this workflow?

Re: A History of IDEs at Google

#143

Post by randomCloud »

wood_spirit wrote: post #14

The last year I’ve been doing all my dev on a vscode VM thingy my company set up. It’s just been getting better and better. It’s like local dev but, tbh, better. It’s at the point where I don’t even install dev tooling locally any more at all. My computer is just a thin client. The aspect I miss is the distributed compilation hinted at in the article. I remember back at the end of 1990s using distcc and things, but t…

This is the other way people work at Google. You have a Vm and then connect IDE of choice to it via SSH. But honestly it’s a lot more effort that just using Coder

Re: A History of IDEs at Google

#144

Post by ajross »

taeric wrote: post #133
computerdork wrote: post #110

Earlier quoted context omitted.

Think for a large tech company, they did a really good job with success in software. For exammple, they were probably the first large tech company to realize AI was actually working, and made it their focus: https://www.businessinsider.com/sundar-pichai-wants-to-build... And yeah, they did/do a lot through acquistions, but seems like most major companies screw up acquistions. Google has it's fair share of failed acqu…

My point on the acquisitions was that a surprising amount of their successful software was not made in house. Again, I don't mean it as a knock against them, necessarily. AI is an odd example. For one, a lot of the research there is from acquisitions. Somewhat feeding back to my first point. They also were seen as tripping up on a lot of the current AI race, no?

> My point on the acquisitions was that a surprising amount of their successful software was not made in house.

First, that's just not true. Their biggest products by revenue (search/adwords) and biggest stock value driver (AI/Gemini/Datacenters) are clearly in-house creations.

But even then, the two biggest "acquisitions" you're probably thinking of are YouTube and Android, acquired in 2006 and 2005 respectively. What fraction of the software base of those products do you think has survived the intervening two decades? To be blunt: most of the software being shipped out of those groups is being authored by engineers who couldn't even read when the ancestral code existed outside of Google.

Honestly the "acquisition" thing is just a cope meme promulgated by Apple stans, as it were. It's not a serious point.

Re: A History of IDEs at Google

#145

Post by randomCloud »

compiler-guy wrote: post #17
taeric wrote: post #12

The advantages of a single platform are as obvious as the disadvantages. In that they are often whatever you want to frame them as for a narrative. I do think Google will continue to get results out of their tooling, as long as they are investing in the tooling. But that is not zero cost. Is it worth it for what they are doing? Largely seems to be. But it isn't like they are that much more successful at software proj…

Google is an ads company with a large amount of infrastructure to back it up. Sure, the money is mostly in ads, but serving searches, AI, youtube, and all the rest at the scale Google does it requires a technical tour-de-force. Does Google do it better than everyone? Absolutely not. But it does it better than many. Certainly it isn't the _only_ way to do it--other companies also manage to do it. But not all that many…

There are things people do in Borg that when ported to our own public cloud kills entire regions. Sure you get limited choice but things work at global scale without thought

Re: A History of IDEs at Google

#146

Post by agmater »

laurentlb wrote: post #56
lzl1234 wrote: post #31

How can they post this obviously internal thing from Google? How can they get clearance from security/IP?

Although the tool is internal, a lot of information about it is not confidential. As the team had to collaborate with the VSCode team, we got clearance for sharing information about it. The screenshots in the article were posted publicly on GitHub (in vscode issues). You can also find screenshots in https://research.google/blog/smart-paste-for-context-aware-a... More generally, a lot has been communicated on develope…

I'd love for more screenshots should anyone have and can share. I still don't get a great picture of how it's running in the browser and I find UI choices fascinating. But I imagine I'd need an NDA to see the settings/options :')

Re: A History of IDEs at Google

#147

Post by randomCloud »

hnthrowaway0315 wrote: post #95
FrojoS wrote: post #90

Earlier quoted context omitted.

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

Pretty much. Also it’s not that slow and you can’t just checkout all of g3

Re: A History of IDEs at Google

#148

Post by top_coder »

mghackerlady wrote: post #27
nostrademons wrote: post #16

Was there 2009-2014 and then again 2020-2026. I think there are a lot of aspects of IDE use and culture at Google that this post omits. My recollection from 2009-2011 is that emacs and vim were the dominant editors (just as the TV show Silicon Valley depicted), and there was a decent-sized minority using Eclipse and Intellij, both of which had official support for Google tooling. The command line still largely ruled…

How many new googlers use vim or emacs do you think? I can imagine at least a small amount of new vim people since vim will always be popular, but I would love to know if more than a handful of new googlers a year use emacs

Famously Jeff Dean uses emacs. Emacs integration to internal systems (source code, code search, LSP, build, etc) was super solid when I was there ~2020.

Re: A History of IDEs at Google

#149

Post by randomCloud »

eddd-ddde wrote: post #130
Arainach wrote: post #91

Earlier quoted context omitted.

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.

This is not a complete answer. There are many open source projects that are developed in google3.

Good old capybara

Re: A History of IDEs at Google

#150

Post by tipsytoad »

kccqzy wrote: post #141
tipsytoad wrote: post #68

Earlier quoted context omitted.

I joined gdm recently, and previously used (neo)vim exclusively. Begrudgingly Cider-V is very, very good. It might be possible to get by without it, but the system is so locked down you’re going to make a lot of sacrifices. (very few authorised extensions, codebase is so large it’s going to break whatever tools your used to using anyway, no git) I’m well thinking I may as well trade my brick of an m5 pro for a 13” ch…

When I was there all the cool people used mercurial. Git5 was creaky and didn’t work well but hg worked brilliantly. The cool people used hg to do stacked CLs so they were productive even when blocked by code review. Fun fact: This particular version of hg with its extensions actually originated from Meta.

We can use jj now, thank goodness. But I still miss my old git workflows + lazygit
Post reply on HN