beliu

In case folks are interested, I had a delightful interview about a year back with Max Brunsfeld, one of the original Atom devs who is now working on Zed: https://about.sourcegraph.com/podcast/max-brunsfeld. (YouTube link: https://www.youtube.com/watch?v=0Jf8AqaZ7IU)

Very excited about where this new collaborative editor goes!

LOL! He did talk a lot about his programming backstory (played with BASIC as a kid, no formal training, chemistry major, discovering Linux) and how this informed his worldview. Bottom-line, he is very results-driven and I think he has a good point about how a lot of tech interviews screen too much for theory and not practice. Turns out you don't need to know how to invert a binary tree to build the most successful package manager of all time :)

This is super common in my experience. Senior/experienced devs spend a bunch of time ramping up the inexperienced or new members of the team and don't have much time remaining to work on their own initiatives.

Patrick McKenzie has a good take on this along the lines of "teach someone to fish" (s/fish/code search/): https://mobile.twitter.com/patio11/status/108611151367121715...

We've tried to make it easier to turn organic code explorations into interactive docs that can be read many times over with a notebook-like feature. Here's a notebook that bobheadxi wrote up after he noticed he was explaining Sourcegraph's authz model for the billionth time: https://sourcegraph.com/notebooks/Tm90ZWJvb2s6NTc0

Thanks! 100% agree with the sentiment that devs should get in front of customers. The best teams I've worked on, the devs have an "end-to-end" sense of ownership, and the organization fosters this sense of responsibility and agency. And great work should absolutely be recognized. It should be a win-win-win—better software for end users, more revenue for the company, and financial + creative satisfaction for developers. We are working with all our might to push the world in that direction.

World's best code search: https://sourcegraph.com/search Analyze code as data: https://sourcegraph.com/insights Interactive docs you'll actually use: https://sourcegraph.com/notebooks Take the pain out of large-scale refactors: https://sourcegraph.com/batch-changes IDE superpowers in code reviews: https://docs.sourcegraph.com/integration/browser_extension

This is really important to call out. There have been a lot of really bad practices in the past that try to reduce "developer productivity" to something that approximates a widget factory, and the results have been awful for both developers and companies. This feeds right into the last section of the post, "If we don't talk about developer productivity, someone else will"—we need more developer voices advocating for the creative spark of building software.

Author of the post here. This really resonates with me. One of the best pieces of advice I've received in my life as a programmer, from my first manager actually, was "focus on getting an end-to-end system up and running first, no matter how janky, and then refine from there".

Sourcegraph CTO (and author of the post) here. There's no part of our product that seeks to track software productivity?

We do have a feature (https://about.sourcegraph.com/code-insights) built around code search that lets devs define their own metrics around things like progress of big migrations and anti-patterns + code smells. This tweet is a good summary of my philosophy around code-related metrics: https://twitter.com/beyang/status/1524259425451577344.

Insights from treating code as data are best discovered by the people who know the dataset through and through—i.e., developers. Another project we've released in this vein is https://codestat.dev, built on top of Comby (incidentally also on the HN front page right now), which was created by a member of our team, Rijnard, as part of his PhD thesis on automatic program transformation.

We're developers by trade and by heart, and are motivated by making tools and mental models that devs actually find useful and that boost the creative spark of coding. If there's something we can improve about our product or message to further this mission, I'd love to hear your feedback!

Sourcegraph actually does do proper semantic linking, integrating with compilers (and type inferencers for dynamic languages): https://docs.sourcegraph.com/code_intelligence/explanations/.... This is one area of significant differentiation between Sourcegraph and GitHub code navigation (which is based on GitHub's semantic library, and which ironically isn't actually semantic in the sense of understanding types as compilers do).

Admittedly, we need to do a better job of articulating this difference, but if anyone would like help getting spun up with precise code intelligence on Sourcegraph, please DM me: https://twitter.com/beyang.

I’m helping with the doctree effort at Sourcegraph. Apologies, the site isn’t actually up yet. This project is still very early stages and we wrote up the README to serve as a sort of launch spec that we could update in response to feedback we receive. We made the repo public so we could build in public but didn’t expect it to receive this much attention this early!

So sorry that the site isn’t up yet. We’ll update the README soon to reflect that. If folks are interested in trying out a super early version, there’s the Docker run command and if you’d like to help us realize this vision, please join our Discord! https://discord.gg/vqsBW8m5Y8

Sourcegraph CTO here. Does anyone know someone at GitHub or Microsoft we could get in touch with to take over maintenance of git.io? There are hundreds of thousands of references in open source, blog posts, and academic papers that will 404 if git.io is taken down. Sourcegraph would be happy to take over maintenance to preserve these links.

Here is a list of open source projects that should update their git.io URLs, ranked in order of popularity: https://sourcegraph.com/search?q=context:global+https://git....

Actually that’s not quite right. We offer auto-indexing now for some languages with more on the way. If neither auto-indexing nor manual LSIF generation are an option, we fall back to our search-based code navigation, which, similar to GitHub’s implementation, trades off accuracy for zero configuration (GitHub’s approach is parser-based while we use a combo of parsing, search, and heuristics that eliminates the need for an index entirely in some cases). This is all documented here for those curious to learn more: https://docs.sourcegraph.com/code_intelligence.

Sourcegraph CTO here. It's interesting to read about GitHub's approach and how it contrasts with the approach we've taken at Sourcegraph. One of the key tradeoffs the article highlights is GitHub's decision to take the "shallow-but-wide" approach to code navigation, which has enabled them to provide some level of code navigation for most open-source repositories on GitHub, but at the expense of precision/accuracy (i.e., the system can't necessarily differentiate between different symbols with the same name).

Sourcegraph decided early on to take the opposite approach, favoring precision and accuracy over supporting every public codebase. Part of the reason why is that we aren't a code host that hosts millions of open-source repositories, so we didn't feel the need to support all of those at once. Another big reason is we heard from our users and customers that code navigation accuracy was critical for exploring their private code and enabling them to stay in flow (inaccurate results would break the train of thought because you'd have to actively think about how to navigate to the referenced symbol). We actually built out a language-agnostic search-based code navigation, but increasingly user feedback has driven us to adopt a more precise model, based at first on our own protocol (https://srclib.org) and also the LSIF protocol open-sourced by Microsoft that now enables code navigation for many popular editor extensions.

This is not to say that GitHub's approach is wrong, but more to say that it's interesting how different goals and constraints have led to systems that are quite different despite tackling the same general problem. GitHub aiming to provide some level of navigation to every repository on GitHub, and Sourcegraph aiming to provide best-in-class navigation for private codebases and dependencies.

(Btw, hats off to the GitHub team for open-sourcing tree-sitter, a great library which we've incorporated into parts of our stack. We actually hosted the creator of tree-sitter, Max Brunsfeld, on our podcast awhile back and it was a really fun and insightful conversation if people are interested in hearing some of the backstory of tree-sitter: https://about.sourcegraph.com/podcast/max-brunsfeld.)

This reminds me of Shaple: https://swag.github.io/shaple

Thank you for this super clear and concise write-up. Used it to write up these instructions for our users and customers to patch the vulnerability across their codebase and sharing here in case it's of use/interest to others: https://twitter.com/beyang/status/1469171471784329219.

Appreciate the feedback here (Sourcegraph CTO). I agree that's annoying. Kicking off a conversation on our end to figure out how to fix that. In the meantime, the workaround would be to create a separate GH login, which can be used to add any public repo to our index. Or what's the URL of the repo(s) you'd like to index and we'll get those added to our index.

Hey Edwin, if you're open to providing feedback, I'd love to understand which types of searches worked well for you in Google Code Search but not in Sourcegraph. We've invested a lot of thought into our query syntax, supporting literal matches, regex, and the Comby pattern matching syntax with a rich set of keywords and filters—but we know the syntax isn't always intuitive for every user. We're always trying to improve the experience for all our users (I'm the CTO at Sourcegraph), so if you have any recollections you're open to sharing, would love to hear them!

Sourcegraph is open-core, with a dual licensing approach. You can run the open-source version here: https://github.com/sourcegraph/sourcegraph#sourcegraph-oss, and we have an enterprise offering for companies that want to adopt for their teams. Similar to GitLab, both our enterprise and OSS code is publicly available.

We built Sourcegraph taking inspiration from Google Code Search (https://about.sourcegraph.com/blog/ex-googler-guide-dev-tool...) to bring the power of code search—and precise code intelligence that just works—to every dev. Try it out here: https://sourcegraph.com. A super common thing we see is people leaving Google, missing code search, and then bringing Sourcegraph into their new org. We'd love to hear your feedback!

Sourcegraph CTO here, I'm very sorry this happened with you. If you shoot me your email (I'm reachable at [email protected]), I'll ensure you don't receive any future sales/marketing emails from us.

This is something we should be clearer and more upfront about. We collect emails for sales purposes from self-hosted Sourcegraph instances, but I agree that entering your email as part of the installation process doesn't mean you want us to email you directly. Going to fix this!

Sourcegraph CTO here, thanks for posting this feedback.

Yes, we do collect information from self-hosted instances of Sourcegraph. (Note to other readers: the blog post is talking about sourcegraph.com whereas what we are discussing here is running a standalone instance of Sourcegraph.) Here is what that info is:

(1) High-level "ping" data (https://docs.sourcegraph.com/admin/pings#critical-telemetry) that includes the email address you put in during installation, the version of Sourcegraph that's running, an aggregate count of users, total codebase size.

(2) Additional telemetry (https://docs.sourcegraph.com/admin/pings#other-telemetry) that includes aggregate usage, latencies, and product actions (e.g., which features are in use, progress through onboarding). This can be disabled in config: https://docs.sourcegraph.com/admin/config/site_config#disabl...

No information about individual user identities, behavior, repositories, or code is sent outside the Sourcegraph instance, unless you explicitly enable a feature (like code monitoring alerts) that does so.

We follow the open-core model and our enterprise-licensed code is also public. You can use Sourcegraph to explore the source code of Sourcegraph and see how telemetry is implemented: https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-....

We collect this data in order to sell our software to companies that use it. We have no plans to charge for Sourcegraph for open-source development, nor will we sell individual user data (which we don't collect).

We've made the decision to make (1) mandatory, because we haven't figured out a better way to ensure we have reasonable awareness of which companies are running Sourcegraph. We do try to keep this data as high-level/aggregate/non-invasive as possible, but I also understand that some might not want to send any data. For folks that fall into that camp, there are a number of other code search engines that are great: Livegrep, Zoekt, Hound, and OpenGrok are ones I'd recommend. If you think the feature set of Sourcegraph is cool and want to use it strictly for personal or open-source development while disabling all telemetry, feel free to reach out ([email protected]) and I'd be happy to do what I can to make this happen.

Of course, if you don't want to run your own instance of Sourcegraph and are okay with using a cloud service, you can also add your repositories directly to sourcegraph.com, where they can be discovered and used by anyone from a single search box :)

If folks have any questions or feedback on the above, I'd love to hear it!

Hey, I'm the CTO/co-founder of Sourcegraph. Thanks for the feedback here. I've opened up a pull request to make it clearer how to disable non-critical telemetry: https://github.com/sourcegraph/sourcegraph/pull/24171. Please let us know if you have any feedback on that!

Will respond to the OP's concerns, which I agree are important, in a direct reply.

Sourcegraph | Full-time Eng, Product, Design | REMOTE | https://sourcegraph.com

We're building the Google for Code and making great code search (the kind that Google, Facebook, and Microsoft have internally) accessible to every company and every open-source project.

* SRE

* Security Engineer

* Sales Engineer

* Software Engineer (frontend, backend, full-stack)

* PM of Growth

* And more, full job listing here: https://github.com/sourcegraph/careers

Tech stack: Go, TypeScript, React, Docker, Kubernetes

You can try before you apply: https://sourcegraph.com/search