Live data from Hacker News

A History of IDEs at Google

laurent.le-brun.eu

101–110 of 333 posts

Re: A History of IDEs at Google

#101
post #85

Earlier quoted context omitted.

I'm not sure about the dates. At some point (2014?), the use of IntelliJ was discouraged in favor of Eclipse. One year later or so, the decision was reversed and the effort focused on IntelliJ (and Eclipse were considered deprecated).

Was there never a detour via Eclipse Theia? I thought it might have had some traction internally, since Cloud Shell is based on it.

Not on the developer side. The cloud side, yes, a bit.

Re: A History of IDEs at Google

#102

> a team dedicated to the IntelliJ integration was formed around 2015 I don't know which team that was, but to add to that, official support for IntelliJ at Google started quite a bit earlier. I was the second person to join a team writing IntelliJ plugins. We wrote a Blaze plugin not too long after Blaze launched, as it was becoming more popular. Google tells me that Blaze launched in 2006, so I think it must have b…

Yes, there were over time, multiple teams working on intellij plugins to support google3 before it all got relatively merged.

You are talking, i believe, about the support for blaze builds in intellij, which was fairly early on, as you point out.

I suspect Laurent is remembering some of the google3 mobile/android efforts, which were much later.

This is just on the "java" side, too. There were other plugins being built that were fairly specific to google3 support.

Re: A History of IDEs at Google

#103
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"

fucking lol, that is how it usually goes with deprecation.

Re: A History of IDEs at Google

#104

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

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…

> You aren't even allowed to keep the source code on your local disk

How is this enforced?

Re: A History of IDEs at Google

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

It is basically VS Code Web. Try https://vscode.dev/ to see how you feel. If you don't like it you won't like cider.

Re: A History of IDEs at Google

#106
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"

haha, that's a great way to put it! And I get the overall gist of it, but why monkeys? :)

Re: A History of IDEs at Google

#107
post #75

Man in building Tritium[1] I have always used the analogy that developers would never program in a web-based IDE. Thus, lawyers would never live in a web-based legal IDE either. In exchange for that we’ve paid the onboarding price of trying to get desktop software installed to even run a demo . This is super timely to push us back towards a reality that web may be viable. [1] https://tritium.legal

Hi Drew, I remember your "Show HN" from a while back and have been secretly rooting for you ever since! (I'm not a lawyer but for some reason I have many friends that are, and now I happen to do work for a firm in the legal publishing sector, so I often hear about how terrible "word processing" can be and think there've got to be better tools!)

May I ask, how are things going? Also, will your IDE always be focusing on transactional law or have you considered expanding to other legal areas and/or markets?

Re: A History of IDEs at Google

#108
Java backend development got pushed to Cider-V from IntelliJ to a degree because the company stopped supporting IntelliJ internal plugins, so not all developers organically moved to Cider-V (and some still use Android Studio to do the non-Android Java development). The forced move got a lot of resistance because of lack of power refactoring features among others in Cider-V.

Re: A History of IDEs at Google

#109
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…

I started a touch before this in London. I recall before Blaze and git5 - every morning we had a ritual of checking out google3 and making sure we could get some sort of build working for the day so that we could then attempt to write some software on top of it. The builds in play were “Mach” and “quickie” or something like that. It was so painful we used to agree that we wouldn’t grab food or coffee or anything until we’d worked out what CL we should sync to for the day to do some work on.

Pair programming was very in vogue and I used to get in a little later than some which was a great excuse to just hop on someone else’s machine who’d already gone through that pain

Re: A History of IDEs at Google

#110
post #64
post #51

Earlier quoted context omitted.

> But it isn't like [Google] are that much more successful at software projects than any other company? I re-read this several times trying to figure out where the irony was hidden. But... it's not there?

Do they have more success in software products than other companies, though? Most of the software many of us know from them, were acquisitions. They still do heavy acquisitions. Notable that they have double the acquisitions of Amazon. They are on par with IBM. A colossal amount of money spent to make things happen. So, again, are they that much more successful at software than other companies? They have more hilario…

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 acquistions, but especially in the earlier half of the company's lifespan, they really did some great one: Youtube, Google docs, Nest...

maybe am biased, but have always thought Google in general does do it better than most tech companies. think it's their focus on the love of interesting ideas vs the love of money (although, that changes more and more as the company ages)

Post reply on HN