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

121–130 of 333 posts

Re: A History of IDEs at Google

#121

Post by piker »

codethief wrote: post #107
piker wrote: 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 o…

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. They're so comfortable with Claude that they for the large part bypass a need for Tritium (or at least they think they do ;). OTOH, large law firms are inundated with legal tech products right now and have a hard time even understanding how an IDE benefits their lawyers. We're also trying to stay away from VC funding (other than from a certain awesome one ;), so we're missing a key signal for enterprise buyers. 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.

That all said, we eliminated the "free tier" as advised back in the Show HN thread, and we've managed to find a very small market in individual users. We're also finding some opportunities with the AI natives using an "unreal engine for legal tech" model that makes Tritium source available and handles the boring editor-related parts of their innovation.

I should probably do a post on this, but there's actually a topic we're working on that perhaps the HN audience will find even more interesting... coming soon!

[edit: I realized that I haven't responded to your question re: other markets, but accidentally did with the hint. We have some ideas.]

Re: A History of IDEs at Google

#122

Post by wmedrano »

ncruces wrote: post #60
wmedrano wrote: post #47

Earlier quoted context omitted.

We've moved on from Git5. Although it was a pain, I kind of liked that Git5 made the monorepo less monolithic to my editor.

Do you mean local checkouts? There's a similar workflow with at least mercurial? Dunno about jujutsu.

When I joined in 2016, it CitC would make it look (and still does) like you had the entire monorepo on your local filesystem on your machine.

Git5 would copy some directories but builds would still fallback to files from the monorepo if you didn't track them. It was convenient for me since I could just grep and do fuzzy matching from my editor. Now I have to do some extra work to avoid grepping the entire monorepo. LLMs sometimes still try to grep the entire repo lol.

Now, you could use a perforace, mercurial, or jj interface and it works fine.

Re: A History of IDEs at Google

#123

Post by hnthrowaway0315 »

flakiness wrote: post #105
hnthrowaway0315 wrote: post #95

Earlier quoted context omitted.

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.

I have used something like that (mentioned in my original reply ^). It was even worse -- there were about 3-4 plugins available.

Basically that company (a well known social media company, not FB) tried to implement everything on their own. Infra is their own (kinda makes sense because it is so huge), IDE is their own, communication is their own (which has an interesting feature that if someone screen shares an internal doc, other people can click a link to access that doc, too, very useful).

I was very jealous about their tooling team (that's what I call real programming), but nevermind I quit after a few months due to some unrelated reason.

Re: A History of IDEs at Google

#124

Post by summerlight »

kayson wrote: post #104
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…

> You aren't even allowed to keep the source code on your local disk How is this enforced?

All the developments are done in a virtual remote file system. From editing to compiling, everything is done remotely. Of course this does not fully stop people from doing manual c&p, but it still makes it hard enough to discourage it.

Re: A History of IDEs at Google

#125

Post by compiler-guy »

taeric wrote: post #64
ajross wrote: 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…

The thing to remember about Google and software is that consumers don't see the vast majority of the software it produces and uses, from the distributed filesystem colossus (https://cloud.google.com/blog/products/storage-data-transfer...) to an enormous number of other internal projects just as complicated as that.

It's user-facing stuff may or may not be great--and the consumer level flops are legendary--but that is only the tip of the software iceberg.

Re: A History of IDEs at Google

#126

Post by hnthrowaway0315 »

bigstrat2003 wrote: post #119
hnthrowaway0315 wrote: post #95

Earlier quoted context omitted.

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

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.

Re: A History of IDEs at Google

#127

Post by summerlight »

lupire wrote: post #53
StilesCrisis wrote: post #21

Earlier quoted context omitted.

Could you even put all of google3 on local disk if it were allowed?!? You'd need quite a RAID array. I suspect it'd be almost impossible in practice.

There's no reason to pull the entire repo just to build one project. Do you pull all of GitHub to your disk?

Because of high coupling dependencies between google3 projects, compiling just a single project usually pulls hundreds of thousands of different build targets.

Re: A History of IDEs at Google

#128

Post by materielle »

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 trace referenced, and overall has a million little features optimized for reading code.

We also have a code reviewer tool, and a separate tool to run and view CI runs.

So what’s left for the editor? Syntax highlighting?

I would tend to view code, run tests and CI, and review in separate tools specialized for their specific use case. The code editor was just a place where I would type in my changes.

I’d imagine this workflow feels weird to people who learned in one-stop-shop IntelliJ and GitHub world. But I can’t emphasize how much better these other tools were compared to GitHib. So a code editor that also lets me read, review, and test code didn’t really matter for me when I had a collection of smaller tools specialized for each individual task.

Re: A History of IDEs at Google

#129

Post by compiler-guy »

bigstrat2003 wrote: post #119
hnthrowaway0315 wrote: post #95

Earlier quoted context omitted.

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

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

Large monorepos have tradeoffs that may or may not make sense for a particular use case. Google's monorepo--in its form as a monorepo, not just the software it contains--is one of its biggest assets and creates enormous leverage.

And an enormous set of problems that must be managed. But multirepos have their own set of issues, and which set of problems you want is highly situation dependent.

Re: A History of IDEs at Google

#130

Post by eddd-ddde »

Arainach wrote: post #91
lozenge wrote: post #87

Earlier quoted context omitted.

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.

This is not a complete answer.

There are many open source projects that are developed in google3.

Post reply on HN