Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An ex-Googler’s guide to dev tools

about.sourcegraph.com

Post reply on HN
Print view View original

111–120 of 219 posts

Re: An ex-Googler’s guide to dev tools

#111

Post by jrockway »

marcyb5st wrote: post #50
anoncake wrote: post #36

Earlier quoted context omitted.

> 1. Why does Google develop their own tools? Because it benefits Google. > 2. Why doesn't Google open source them? Because that would benefit the competition.

Disclaimer, I work for Google, but what follows is my personal opinion. Google open-sources a lot: Tensorflow, K8S, Apache Beam, ... . And even if it doesn't end up as fully open sourced project, Google still releases white-papers on the subject that allows startups to create something similar (Cockroach-DB for instance). However, while I admit that some decisions might be made to avoid benefitting competition (I thi…

What Google open sources and doesn't open source is strictly a business decision. The technical details don't matter. Things like Spanner remain proprietary because Google thinks they can make money with it. They charge $10/hour just to have the replicas up and serving traffic; letting Amazon install it and charge $9.95/hour is not something they think is going to make GCP a lot of money, so we don't get the source code. Things like Kubernetes, on the other hand, are open source because Google wasn't "winning" in that area -- to get people to use GCP, they had to get people to break the dependency on proprietary things like CloudFormation. Otherwise, people would just stay at the market leader and not switch to the second place option.

Plenty of people outside Google use protocol buffers, for example; I've run into them at every job I've had since Google, and in plenty of strange places that probably never cross-pollinated with Google (the most surprising place I found them was in Hearthstone). They're pretty popular and people aren't really surprised to see them anymore.

I think there is also a middle ground where people inside Google don't think there's interest, but there is. For example, I very much miss Monarch. I don't think the code is making them a lot of money; my understanding that the Cloud monitoring stuff is completely different. But it is way better than Prometheus or InfluxDB. Queries that are trivial in Monarch you simply can't do with those products. (The one thing I found most valuable in Monarch was that pretty much every query started with an "align" step. And I just haven't seen that anywhere else, so it's hard for me to reason about what the query is actually doing.)

As other people mention, the mere task of picking the transitive closure of dependencies out of google3 is hard. In fact, maintaining a bunch of non-monorepos is a huge chore compared to monorepos once you have the right tool. It's thankless work, literally, so I can believe that's one reason why there aren't more internal Google tools open sourced. But, it can be done if there is some thanks for doing the work. When Google split into Alphabet, work was done to let companies leaving Google take their chunks with them. There just had to be some sort of business reason to justify the tedium.

Re: An ex-Googler’s guide to dev tools

#112

Post by Tyr42 »

dessant wrote: post #96
Cthulhu_ wrote: post #90

Earlier quoted context omitted.

I have one experience with that. Guy, late 20's or early 30's at best, ex-Googler joins a bank and becomes CTO. Pushes for them to replace Angular (which they went all in on, migrating from a set of JQuery UI components) with, drumroll, Polymer. Nothing finished yet, performance issues (because guess what, polymer's routing turned out to be pretty much the same as a 'tab panel'), aaand Polymer 2 rolls around, backwar…

One of my worst decisions as a developer was to build upon a component framework maintained by Google. Material Components for the web is constantly introducing breaking changes that make building upon the framework a nightmare. Lately they've even set this expectation in the project description. The problem is that the components are rather buggy, so you must regularly update them to have upstream bugs fixed. > Mate…

I feel like the breaking changes must be because they're used to working in a monorepo, where you can just change the code and the clients at once. No need to worry about compatibility

Re: An ex-Googler’s guide to dev tools

#113

Post by paulryanrogers »

JeremyNT wrote: post #102
Cthulhu_ wrote: post #92

Earlier quoted context omitted.

I would've loved to have Gitlab at our company, but unfortunately we're on a tight budget so they didn't want to go for anything paid.

Gitlab CE would be perfect, then, since it's free. If you're on a tight budget it actually seems like one of the best options available.

Tried self hosting once and it was challenging just to get setup. That said their free hosted solution is feature such enough for most of my projects.

Re: An ex-Googler’s guide to dev tools

#115

Post by u801e »

raverbashing wrote: post #65
tdeck wrote: post #11

> Many years ago, I did a brief stint at Google. A lot has changed since then, but even that brief exposure to Google's internal developer tools left a lasting impression on me. Perhaps the operative phrase being "Many years ago". I currently work at Google, previously I worked at Square. Of the two, I generally prefer the OSS and off-the-shelf tooling at Square. Some things really are better at Google (code search a…

Yes please, Github PRs are much, much better than Gerrit or Ritveld (urgh), and the +1/+2 quirks of it No, I'll take Github PRs any day. They could be better, of course.

Github PRs (at least on the enterprise version) still have the problem of collapsing comments where the associated line of code changed in some way that had nothing to do with the comment. They also require a lot of scrolling if the overall diff is rather long. And, they still don't provide a way to comment on commit messages themselves.

Re: An ex-Googler’s guide to dev tools

#117

Post by vageli »

cobbzilla wrote: post #71
burakemir wrote: post #17

(Googler here) The article is a good description of the tools, and I was not aware of the blaze clones plz and pants. One thing that is maybe not obvious: For an API author, code search in combination with a monorepo and the somewhat hermetic universe which is Google's code base provides immediate access to all uses of a library. You can see what worked well and what didn't, and it enables effective refactorings. Tha…

> code search in combination with a monorepo and the somewhat hermetic universe which is Google's code base provides immediate access to all uses of a library. You can see what worked well and what didn't, and it enables effective refactorings. That also means when writing a client, you can quickly figure out from other client code how stuff is supposed to be used. ... If anything like this were possible for open sou…

> gets me thinking — this is totally doable for open source code. someone just needs to build some giant indexes across git repos + package repos (maven/npm/pip/etc)...

Sounds a lot like sourcegraph.

Re: An ex-Googler’s guide to dev tools

#118

Post by jonhohle »

antoinealb wrote: post #60
ikiris wrote: post #53

Earlier quoted context omitted.

Here I'm sitting here thinking could I draw it from memory?

It went through a re-design recently. I don't think I would call it a well-guarded secret though, if you look at Phabricator's Differential, it is very similar [0]. [0] https://www.phacility.com/phabricator/differential/

Reading through that page it seems like every single component is an unrelated, seemingly random, “cute” name. Are cli, triggers/actions, and rules too generic? Out of context, what meaning do Arcanist, Maniphest, or Herald have?

Re: An ex-Googler’s guide to dev tools

#119

Post by raverbashing »

u801e wrote: post #115
raverbashing wrote: post #65

Earlier quoted context omitted.

Yes please, Github PRs are much, much better than Gerrit or Ritveld (urgh), and the +1/+2 quirks of it No, I'll take Github PRs any day. They could be better, of course.

Github PRs (at least on the enterprise version) still have the problem of collapsing comments where the associated line of code changed in some way that had nothing to do with the comment. They also require a lot of scrolling if the overall diff is rather long. And, they still don't provide a way to comment on commit messages themselves.

Agreed on the comment collapse, about comment on the commit message I'd say it's a commit on the main PR (since by the time the PR is done the commit msgs are pretty much not changeable, except for the last one)

Re: An ex-Googler’s guide to dev tools

#120

Post by randomsearch »

prepend wrote: post #29

Sourcegraph seems interesting but the pricing seems off for me. The “Teams” plan costs $150/month for 25 people and that works out to $6/user/month. Using GitHub it’s between $4-21/user/month. So this means that insight from my source costs sometimes more than actually managing my source. I’ve never worked at Google but it seems like one benefit is that they’ve figured out how to scale the costs of this kind of funct…

There must be a name for this psychology:

“Product A is great value and product B is more expensive than (or same as) product A therefore product b is bad value and I won’t buy it.”

The ROI or otherwise of a product is not related to the first one. Unless your budget is so limited it’s either-or, why is this fallacy so prevalent?

Post reply on HN