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

161–170 of 333 posts

Re: A History of IDEs at Google

#161

Post by laurentlb »

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…

For security reasons, the VSCode marketplace is not accessible, but many (in the 3-digit range) external extensions have been imported. One technical limitation is that some extensions are not designed for the web (e.g. try to run local things).

Re: A History of IDEs at Google

#162

Post by [deleted] »

kridsdale3 wrote: post #139
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...

As an employee, I'm using Antigravity (CLI version) every day (because we can't use Claude) and it rules. I am way more productive than I was with CIDER-V, which itself was very nice.

[deleted]

Re: A History of IDEs at Google

#163

Post by hcnews »

randomCloud wrote: post #159
spwa4 wrote: post #154

Earlier quoted context omitted.

There was also the code search, uh, I forgot the name "quick change", I believe? Very handy for seeing a problem, quickly solving it (sending out a CL) marking it autosubmit and just moving on.

I assume quick change became critique?

There was a code reviewer starting with M before Critique iirc (Mondrian I wanna say?). The M code reviewer was completely written in Python iirc.

Re: A History of IDEs at Google

#164

Post by hollowcelery »

richardboegli wrote: post #142
materielle wrote: post #128

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

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

Sourcegraph is the closest external thing I've found to Google's internal web tool for viewing code.

Re: A History of IDEs at Google

#165

Post by aleksiy123 »

hnthrowaway0315 wrote: post #126
bigstrat2003 wrote: post #119

Earlier quoted context omitted.

To be fair, that is a blessing. Large monorepos are a terrible idea.

I have always had this itch to work on some real life serious system programming projects, with the most recent wave OS kernels. I completed the MIT xv6 labs (a very small repo) and did a few Linux device driver labs (very large repo and it was the first time I experienced compilation time > 5 minutes). I got burnt out after a while, so that kinda wrapped up my experience working on large repos.

thats just a large project tho? not necessarily a mono repo.

A mono repo doesn't necessarily mean large compile times, because it depends on the projects and their dependencies within that repo.

Re: A History of IDEs at Google

#166

Post by aleksiy123 »

computerdork wrote: post #106
DannyBee wrote: post #100

Earlier quoted context omitted.

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? :)

code monkeys

Re: A History of IDEs at Google

#167

Post by piker »

codethief wrote: post #135
piker wrote: post #121

Earlier quoted context omitted.

Hi! It's a super interesting time to be in legal tech. Thank you for asking. When this project got started, "VS code for transactional lawyers" was the target. We pretty well have that on offer at this point, but it sits in a weird spot making it harder to sell than it would be in, say, 2024. Right now, "AI forward" lawyers are spinning out of law firms in droves to start "AI native" firms backed for example by YC. T…

Wow, thanks so much for taking the time to answer my questions in detail! > As I mentioned above, it's super hard to even set up a hands on demo because we have to get the desktop app installed on their infrastructure. But I'm shocked to learn that Googlers are happy to work in a browser, and distributing Tritium via browser is trivial, so we're going to 180 on that right here and now. "Trivial" in the sense you can…

> "Trivial" in the sense you can just compile everything to WASM? I'd be curious to know what such an IDE would feel like in the browser. I think the only WASM-based GUI apps I've tried in the browser were Flutter apps and those were… weird.

Yes, that's about it. We rely on threads a lot in the desktop version which doesn't map as easily to WASM so there is still some work to do. But if you remember back to the original Show HN post, it was running in the browser there. So we have experience with it.

There is a bit of uncanny valley that comes with using WASM with in the browser like we do rather than the DOM. There aren't reflow events in the same way, and frankly it's just a lot snappier than you expect. But it comes with a lot of trade-offs and you're forced to reinvent the wheel if you totally abandon web primitives.

Re: A History of IDEs at Google

#168

Post by agmater »

laurentlb wrote: post #152
agmater wrote: post #146

Earlier quoted context omitted.

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 :')

It's VSCode, so it's 90% similar to https://vscode.dev There are internal extensions, but they don't dramatically change the look and feel. I think many VSCode users are not familiar with the Comments UI, but it's used in e.g. the "GitHub Pull Requests" extension. Apart from that, some changes in the list of directories/files (for performance reasons) and a redesigned SCM integration.

I see that makes sense, thank you!

Re: A History of IDEs at Google

#169

Post by steveklabnik »

richardboegli wrote: post #142
materielle wrote: post #128

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

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

The startup I'm at (ersc.io) is working in this space (version control more than the IDE side of things), because, in my opinion, there just plain isn't any.

Re: A History of IDEs at Google

#170

Post by benoau »

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…

> Engineers being unhappy when things change and when the slightest thing works differently is the least surprising thing I've ever heard.

Gold.

Post reply on HN