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

281–290 of 333 posts

Re: A History of IDEs at Google

#281

Post by taeric »

rossjudson wrote: post #207
taeric wrote: post #156

Earlier quoted context omitted.

Certainly fair. But they have tried some amusingly ambitious projects that make it pretty easy to raise eyebrows. Stadia alone is enough to make me nervous on any efforts they announce that are ambitious.

Stadia was pretty technically awesome, and also a rounding error on Google's overall engineering budget. "Ambitious" engineering means something very different inside of Google. Example: Spanner. Infra Spanner is correctly described as a "generational achievement". Very few people outside of Google have any idea that it exists, or what it does, and that's fine.

Stadia was yet another platform that Google tried to make and failed. Yes, it was a rounding error in their budget, but that is largely the point!

They have become a financing company that is looking for where to spend money to make money. That they are spending a lot of money on developers will only last as long as that makes them money.

Again, this is not, necessarily, bad. I just don't trust them to make a software product that will survive outside of their garden.

Re: A History of IDEs at Google

#282

Post by achille »

kccqzy wrote: post #277
achille wrote: post #181

Earlier quoted context omitted.

Yep, I made my own! (Xoogler 2017-2023) this is my noogler IDE story, one of my favorite, proudest hacks! I developed a fork of the IntelliJ IDE on my second week at google out of raw frustration over latency. At the time I was commuting 2-3hrs/day SF MTV on the gBus. Connectivity on the bus wasn't optimal, and there was high latency. Cider didn't have deep integration, and wasn't able to let me explore and understan…

I’m surprised you find ssh+vi having medium typing latency. I have ssh’ed to either my desktop to (later) my cloudtop and latency has always been great. The ssh latency is good enough that I can run X forwarding to launch graphical instances of emacs and gvim. The latency was basically unnoticeable. Later I rented a vacation home in South Lake Tahoe and worked remotely. It was only then that I realized it had terribl…

latency on the gBus was at the time ~250msish but would regularly spike much more on certain sections. Each keystroke would have to roundtrip before appearing on the screen.

Using something like mosh would mitigate it, but there was no UDP tunnel available through beyoundcorp.

Cider and MDProxy were running rendering locally so the keystrokes were nearly instant.

Re: A History of IDEs at Google

#283

Post by ecshafer »

isaacdl wrote: post #269
MarkSweep wrote: post #183

Earlier 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??

Wow that is a lot faster and nicer than Github.

This is a good example of large companies wouldn't send someone across the street to pick up $1M off the ground. If Google actually released that and a repo to public, they could take Githubs throne. But a few $B business isn't worthit for them.

Re: A History of IDEs at Google

#284

Post by ianhxu »

Been using Cider for two years now. Early on I struggled, trying to use IntelliJ, and even tried the thin client version — but both are basically in maintenance mode. Cider is the de facto standard. It really is the best IDE in terms of integration with internal tools, but it also inherits Google internal tooling’s general disregard for UX quality and aesthetics.

Re: A History of IDEs at Google

#285

Post by the_arun »

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…

Every large tech company of 80s, 90s & 2K (Google, eBay & all) have similar history when it comes to IDE, Source Control, Build Systems etc.,. This is not specific to Google.

Re: A History of IDEs at Google

#286

Post by rockemsockem »

ianhxu wrote: post #284

Been using Cider for two years now. Early on I struggled, trying to use IntelliJ, and even tried the thin client version — but both are basically in maintenance mode. Cider is the de facto standard. It really is the best IDE in terms of integration with internal tools, but it also inherits Google internal tooling’s general disregard for UX quality and aesthetics.

The aesthetics are literally vs code though .....

Re: A History of IDEs at Google

#287

Post by taeric »

VirusNewbie wrote: post #171
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…

If GCP was its own company it would almost be a Fortune 50 company on its own. Youtube would be a Fortune 100 company. That seems a lot more successful than most software companies. Meta on the other hand, really just has ads.

Question is if it got there purely on the merits of the software? Marketing and general infrastructure build out were far more influential in their rise.

Again, I am not meaning this as a knock on their strategy. It is valid and is producing real results. I just don't think their unified IDE is a meaningful contributor to it. The equivalent of boots on the ground is far more of a contributor there.

I had similar complaints about AWS back in the day. It wasn't a lack of ML offering in AWS that made Amazon Photos less useful than Google's photo offering. Despite what some internal folks would say.

Re: A History of IDEs at Google

#288

Post by taeric »

FergusArgyll wrote: post #89
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…

The catch is that you need to build good software so people use it so that you can show ads

The caveat to that, though, is that "good" is another term that you can frame however you want.

Re: A History of IDEs at Google

#289

Post by perkovsky »

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…

[dead]

Re: A History of IDEs at Google

#290

Post by keeda »

SkiFire13 wrote: post #239
keeda wrote: post #62

Earlier quoted context omitted.

I would imagine Android development, with its reliance on simulators for local UI testing, is pretty complicated to shoehorn into a web-based IDE? I think cloud-based IDEs would only really work for anything for which a text or web-based UI suffices. (Which is already quite a lot: that covers code, logs and web pages.) For anything with native UIs, I suppose you could "remote desktop" into an app or a simulator runni…

> with its reliance on simulators for local UI testing I can run an Android app on my phone and have it pop up in Android Studio. I don't see a reason you couldn't do this with a remote simulator or even a remote physical phone.

Right, on a LAN things are fine, but when it's in the cloud and the latency jumps to 100+ ms I would imagine it would make for a very laggy experience. Cloud gaming tackled these same problems but that required a huge investment in infra and R&D. At that point it would just make sense to hand out more powerful laptops with IDEs for local development.
Post reply on HN