News for hackers. Stuff that matters.
Re:How Google Code Search Worked (2012) by dvirsky on Thursday March 12, 2020 @01:21AM (#22554019)
The current internal CodeSearch is one of the best tools available for Google engineers. It's really a marvel.
Re:How Google Code Search Worked (2012) by tehlike on Thursday March 12, 2020 @03:06AM (#22554495)
Code search, critique, Piper/citc/cider are amazing for developing

Power drill is fantastic for drilling down data. So much money was made thanks to this one.

Re:How Google Code Search Worked (2012) by dvirsky on Thursday March 12, 2020 @12:01PM (#22558175)
Piper was actually a big source of frustration for me. Yeah it's dead simple, but once you have a CL chain, you're entering a world of pain. I've switched to Fig a while ago and haven't looked back. Beyond a tiny fix I'll start editing from CS or a throwaway citc client, it's just simpler to use fig. I've been able to juggle 4-5 CL chains easily and it makes my workflow much easier. Also splitting CLs before review is much simpler with Fig.
Re:How Google Code Search Worked (2012) by ignoramous on Thursday March 12, 2020 @04:40AM (#22554891)
Are these code tools built using https://github.com/kythe/kythe ? Any other OSS projects by Google that back these?
Re:How Google Code Search Worked (2012) by cameronbrown on Thursday March 12, 2020 @06:40AM (#22555418)
I believe so. Kythe seems to have spawned out of the internal CodeSearch.
Re:How Google Code Search Worked (2012) by hangtwenty on Thursday March 12, 2020 @11:12AM (#22557674)
Something that is not by Google but which you would probably like - SourceGraph. Has commercial options but it is OSS.

https://about.sourcegraph.com/

Re:How Google Code Search Worked (2012) by jules on Thursday March 12, 2020 @03:43AM (#22554639)
Do you have a list of all major Google tools and why they're better than what's available elsewhere? (if so)
Re:How Google Code Search Worked (2012) by antoinealb on Thursday March 12, 2020 @06:42AM (#22555423)
In my opinion, what makes them really great is the tight integration that they have. For example, since the whole company uses one build system and one single repository, you can build a truly awesome IDE that knows about every library in the company and can autocomplete for it. Same for code search, where cross references are accurate and work cross languages (for example a class generated from Protobuf).
Re:How Google Code Search Worked (2012) by londons_explore on Thursday March 12, 2020 @06:57AM (#22555494)
Outside Google, the percentage of my coding time I spend hunting some dependencies source tree for the relevant header files or documentation or "Where on earth is this constant defined" is huge.

With codesearch, answering those kind of questions is near instant.

Re:How Google Code Search Worked (2012) by cameronbrown on Thursday March 12, 2020 @06:41AM (#22555420)
Re:How Google Code Search Worked (2012) by dvirsky on Thursday March 12, 2020 @12:10PM (#22558262)
So CodeSearch, Critique, Borg, Sherlog, Cider come to mind as top notch tools that are not available outside. As far as libraries go, the C++ Fibers thing is incredible and I don't think it's open.

Blaze is amazing (albeit a bit slow) but Bazel should be more or less the same, haven't used it. Dremel, Spanner, Tensorflow, Proto, grpc are all available outside. Abseil (https://abseil.io/) is a great library available to everyone.