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

211–219 of 219 posts

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

#211

Post by randomswede »

thrweo24324324 wrote: post #75
tdeck wrote: post #12

Earlier quoted context omitted.

Perhaps, but what's notable about Google is the extent to which everything is a text config file, and the fact that everything is in a monorepo. As an example that surprised me, even our oncall rotations are kept in a text file along with a list of upcoming assignments. The rotation tool checks out that file and appends the next few names in the list to the end of that file to prepare the "calendar" for the coming we…

Yes, but on the other of the spectrum, GCL itself has turned into another half baked programming language. Editing these configs is the bane of my life.

GCL is the thing I was looking forward to never seeing when I left Google. Now, GCL is one of the things I actually miss.

Pretty much all other "configure things that are at least moderately complex" are actually bad enough that it makes GCL/BCL look like a really good idea.

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

#212

Post by higerordermap »

thrweo24324324 wrote: post #73
tpetry wrote: post #19

Earlier quoted context omitted.

Declaring a FAANG company failing because it‘s toolset is antiquated is the rare hn elitist opinion you see here more and more. Are startup people in the valley more and more becoming blind to the real world?

There is a certain kernel of truth to it. I work at Google, and doing anything at all is a chore - it's almost as if we're back to programming with punch cards. It's not surprising that Python doesn't work well in such a high-delay dev environment.

Hi, can you elaborate the high delay part? Is it the case that all code is accessed through internal network using FUSE or something? Or is it because monorepo?

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

#213

Post by mark_l_watson »

I used Docker to install sourcegraph yesterday on my MacBook. It took a while to locally cache about 2 GB of data from my 130 GitHub repos. I think this is a game changer, but I need a few weeks with it to make sure that the ceremony is worth the effort. I should probably be running it in a VPS rather than my laptop. I worked as a contractor at Google in 2013 and I do miss their internal dev environment.

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

#214

Post by jdbernard »

antonvs wrote: post #208
jdbernard wrote: post #166

Earlier quoted context omitted.

The system makes sense but it feels like there is probably a more intuitive easy to express those than with numbers. Naming is hard, of course, but off the top of my head maybe something like -1: Changes Requested -2: Declined 1: Approved 2: Accepted

Why would that matter? This is for developers, not English majors.

I didn't down vote you, and your question deserves a serious reply because the same principle is broadly useful.

Communication is hard. People actively in the team probably have the context to understand the differences, but that implied context is what tribal knowledge is made of.

OP indicated that there were non-trivial "non-linear" differences going from 1 to 2 and -1 to -2. The use of numbers implies a relationship that doesn't really exist. The use of accurate language makes the actual meaning immediately obvious without the need for implied context. For example, I had no idea that only privileged devs could give 2s. "Accepted" and "Declined" do imply a finality that more accurately mirrors the intended usage.

This may seem overly analytical for something that is easy to just explain, but this kind of thing build up in layers.

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

#215

Post by mlazos »

snazz wrote: post #174
alisonkisk wrote: post #150

Earlier quoted context omitted.

What does it mean to have plural monorepos?

Org-wide instead of company-wide, maybe?

Correct, I was working in exchange where all of the teams and orgs working on that worked out of a single large repo and never touched other products.

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

#216

Post by ericyu3 »

madhadron wrote: post #145
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.

Stacked reviews are the crucial thing missing from GitHub pull requests. Truly, once you get used to working wit hthose, going back is intolerable, to the point where I now have a hacked together workflow where I live in git rebase -i and have it automatically push specially named branches for each commit in a stack.

So a few months ago I actually found a tool for this! The tool makes it easy to manage stacked reviews on GitHub. It's working super well for me. I also showed it to a bunch of people I work with, and a lot of them have taken it up.

Link: https://github.com/ezyang/ghstack

If you're interested, I'm happy to talk you through it - just book some time here: https://calendly.com/ericyu3/15min

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

#217

Post by tdeck »

jdbernard wrote: post #214
antonvs wrote: post #208

Earlier quoted context omitted.

Why would that matter? This is for developers, not English majors.

I didn't down vote you, and your question deserves a serious reply because the same principle is broadly useful. Communication is hard. People actively in the team probably have the context to understand the differences, but that implied context is what tribal knowledge is made of. OP indicated that there were non-trivial "non-linear" differences going from 1 to 2 and -1 to -2. The use of numbers implies a relationsh…

Exactly this. It's not as if two +1s equals a +2 (which one night intuitively think based on the nomenclature).

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

#218

Post by sershe »

dboreham wrote: post #107
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…

> integer in the range [-2, 2] for some reason This sounded awesome to me (imagining some Fortran code behind it), but disappointingly the cited screen shot only has the range [-1,0,1] which is hardly the same.

I think this might come from a typical feedback on patches in Apache (or all of OSS) - -1 rejected as is, +1 approved. I've also seen -0 (don't approve but won't block/reject) and +0 (ok with it but didn't review/won't approve)

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

#219

Post by dcreager »

breck wrote: post #131
cobbzilla wrote: post #71

Earlier quoted context omitted.

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

GitHub is moving in this direction (they now show interpackage dependencies at the package level, and intra dependencies at the symbol level. However, neither works great—maybe 30%-80% coverage?, and far from "in a way that gets near complete coverage" that the parent stated about the benefit of Google's monorepo. It may be a case where you need 90 or 99 or even higher coverage before it becomes a game changer. But I…

Hi there! I manage the GitHub team responsible for the Code Nav part of this. Re 30-80% coverage, can you elaborate on the biggest missing piece for you? Is it the number of languages that are covered, or too many false positives in the results we show? (Or something else?)

For the latter, it's a known limitation in that we're only doing "fuzzy" or "c-tags-like" Code Nav — defs and refs are only matched by their textual unqualified symbol names. For some languages that's not a big deal, because symbol names tend to be unique. But for a language like Go, you might have dozens (or hundreds!) of methods named "Parse", and we don't currently distinguish those in our Jump to Def UI.

That's something we're actively working on, though! One benefit to the current fuzzy approach is that it's incremental (we only have to analyze changed files in a commit), and does not depend on tapping into a build or CI process. That makes it much faster — we have a long-running indexer service live and hot, and typically have new commits indexed and live in the UI within 1-5 seconds of receiving a push. And it requires no configuration on the part of the repo owner — no need to tell us how to build your project, or to configure an Actions workflow to generate the data. That makes it easier for us to support entire ecosystems when we roll out support for a new language. We've also tried to make it fairly easy for external communities to add support for their languages — this is all driven by the open-source tree-sitter parsing framework. This file, for instance, is where the symbol extraction rules for Go are defined: https://github.com/tree-sitter/tree-sitter-go/blob/master/qu...

We've been working on a new approach to generate more precise symbol data, while keeping those incremental and zero-config properties. It's not ready for public launch, yet, but it's close!

For those who want to learn more, I gave a talk at FOSDEM 2020 (back in the Before Times) going into more detail on some of these constraints and design decisions. (Though please note that this talk references a legacy way of defining symbol extraction rules, which relied on writing code in our open-source Semantic project.) https://dcreager.net/talks/2020-fosdem/

Post reply on HN