Live data from Hacker News

Cloud Source Repositories

cloud.google.com

71–74 of 74 posts

Re: Cloud Source Repositories

#71
post #50
post #46

Xoogler here. Internally as Google, you have a substantially power powerful version of Codesearch, which is semantic, i.e. it relies on actual binary artifacts produced by builds to index code. All of the code base uses Blaze ( open sourced as Bazel) to express the rules. The version of code search here is cute, but it's still not a full blown structured semantic code search, which I really miss. Searching for and br…

> I think Sourcegraph is trying here but that still does not seem to use some kind of accurate and structured information like you have in the code, it still seems not use build rules Sourcegraph does use language servers (same as your editor would use) to get precise definitions and references. For example ("find references" on some open-source code): Go: https://sourcegraph.com/github.com/theupdateframework/notary.…

Thank you for the reply, appreciate you reading the comments so thoroughly.

My top piece of feedback is considering some form of a strict mode, where your vision is not best effort support support for some legacy tool for a language, but fabulously amazing knock your socks off good support for users who take the time to invest in making their build friendly with your search index.

It might seem tempting to go after the longest common denominator audience here, but personally I think it's far more valuable to show users how code search can be amazing if they do their part to invest in it, vs. code search being "kind of sort of useful" if you have a fallback.

And maybe my Xoogler experiences are showing here, though Bazel / Kythe are in my opinion the perfect vehicles to realize that vision.

Re: Cloud Source Repositories

#72
post #71
post #50

Earlier quoted context omitted.

> I think Sourcegraph is trying here but that still does not seem to use some kind of accurate and structured information like you have in the code, it still seems not use build rules Sourcegraph does use language servers (same as your editor would use) to get precise definitions and references. For example ("find references" on some open-source code): Go: https://sourcegraph.com/github.com/theupdateframework/notary.…

Thank you for the reply, appreciate you reading the comments so thoroughly. My top piece of feedback is considering some form of a strict mode, where your vision is not best effort support support for some legacy tool for a language, but fabulously amazing knock your socks off good support for users who take the time to invest in making their build friendly with your search index. It might seem tempting to go after t…

Very good points, thanks! We will be exposing a lot more configurability and extensibility in Sourcegraph in the next release (3.0-preview, and 3.0 more generally). I will add Kythe support to our roadmap and will think about how we can offer a strict mode soon. (We will need to offer that when Sourcegraph supports "write" functionality like automated refactoring, but it would be great to have it sooner.)

Re: Cloud Source Repositories

#73
post #12

It wasn't all that long ago that Google shut down Google Code. They said: https://opensource.googleblog.com/2015/03/farewell-to-google... > After profiling non-abusive activity on Google Code, it has become clear to us that the service simply isn’t needed anymore. And now they've created a new product which does pretty much the same thing... Wonder how long this one will last.

I disagree that CSR serves the same purpose as code.google.com, and is likely to meet a similar end. code.google.com hosted public repos, issues, wiki, downloads, etc., and was generally just ripe for abuse. Google created it largely because Sourceforge was the only thing that existed at the time, and it wasn't doing a great job. Today there's GitHub, Bitbucket, Gitlab, and more. CSR is primarily for hosting private…

Hi, Jason! Thank you for the awesome work with Cloud Build :)

Re: Cloud Source Repositories

#74
post #70

Earlier quoted context omitted.

How do you deal with things like system headers then? Force everyone to check in their OS (bye BSDs)? Assume everyone runs the same OS? How do you deal with compiler provided internals, where someone might be using clang which has behavior X, but gcc / icc / msvc doesn't? These problems are more prominent in C/C++, but are everywhere... Not easy... Google can probably check in everything for themselves... Probably no…

My understanding of this is the Google approach is to have all builds in the cloud using Forge i.e. infrastructure that lets you cloud builds. This means you can do hermetic builds, and thousands of other engineers can reuse the build artifacts you produce. And in the particular context of tools such as code searching, your build artifacts update the code searching index pretty quickly post committing a change.

My point wasn't how do you build these things. It's how you index them.
Post reply on HN