SQsqs·Sep 21, 2018
Hey, Brian! Our (Sourcegraph's) unique role is that we have a product used by a ton of developers to search and browse code (in public and inside their company), so we have an audience for distribution of these tools. We also have some expertise. So, I envision most of our work being on that, and perhaps a few reference implementations of language servers and other APIs, and then letting the true language experts outside of Sourcegraph own the language-specific parts.
This is because the best people to build language servers are the language maintainers/experts themselves. A great language server should be a core part of every programming language, just as most languages have packages for parsing their own AST, typechecking, etc. (E.g., the javac API, go/types and related packages, and the TypeScript API.) This is incentive-aligned becaus
Read the rest
e great tooling boosts language adoption.
Rust has done a great job here, with an official language server (https://github.com/rust-lang-nursery/rls). The Go team is investigating building an official language server, which we would love (we built an unofficial one and are happy to deprecate it in favor of an official one, or help make it official--whatever is easiest for the Go team/community).
For languages that don't yet have a good language server, we would dearly love to sponsor the creation of one, but it's quite time consuming to do so. It takes a while to find the right person to build it for each language (esp. for languages we aren't familiar with), and the majority of these projects have not yielded a working language server, so that hasn't been as easy as we had hoped. This is the main bottleneck.
And in all cases, we want to make it so there's a huge reward to building a great language server. When you build a language server, you can use Sourcegraph to run it for all code you view on GitHub, Bitbucket Server, and (soon) other code hosts. That means you get hovers, go-to-definition, find-references, etc., in code files and PRs in your existing tools. (See https://chrome.google.com/webstore/detail/sourcegraph-for-gi... or the Firefox extension to start using that.) The process for taking a language server and deploying it to Sourcegraph currently requires some intervention from us, but we are changing that with https://github.com/sourcegraph/sourcegraph-extension-api. This will also make it much easier to take a language server and make it work in all editors, without writing per-editor shim extensions.