beyang

* Full code intelligence platform (not just code search) with Code Insights for tracking trends (https://about.sourcegraph.com/code-insights) and Batch Changes for large-scale refactors (https://about.sourcegraph.com/batch-changes)

* Precise code navigation (vs. more fuzzy-level nav), powered by SCIP (spiritual successor to Grok, the system Steve built at Google)

* More powerful search language beyond regex (supports comby.dev) + user-friendly (smart search)

* Works across multiple GitHub instances + other code hosts (GitLab, Bitbucket, Perforce, enterprise Git repositories)

* Self-hosted deployment and enterprise scale

cs.github.com is a significant improvement over github.com/search—kudos to the team there!—but is about feature parity with something like OpenGrok, Hound, or Google Code Search before Steve built and integrated Grok (primarily cross-codebase regex search).

Sourcegraph's licensing is open core (similar to GitLab): https://handbook.sourcegraph.com/departments/engineering/pro....

Our code is public, regardless of whether it is open-source or enterprise licensed. The open source code includes most of the product features; the enterprise code includes things like enterprise AuthN, AuthZ, and admin capabilities that are needed for large companies to use Sourcegraph.

Sourcegraph.com/search indexes over 6 million open-source libraries, nearly every github.com repository with at least 5 stars and the most popular projects across NPM, PyPI, Maven Central, and many more independent projects and code hosts.

Sourcegraph CTO here. We're elated to welcome Steve to the team and will be hosting a Twitter live / AMA (https://twitter.com/sourcegraph/status/1577364344056201236) with him tomorrow at 1pm PT. Join us if you're free!

Ironically, some of the steps that Bazel takes to make builds hermetic make it more difficult to integrate with to pull the information we need out of the build for precise code navigation. But we're working on it :) If this is an area of interest to you, pop into our community Discord and say hello!

Similar concept: https://news.ycombinator.com/item?id=31948833

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 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.)