Wrapping language servers gave us remote execution of the language server, but lsp-adapter did not solve more fundamental problems related to incompatible compiler and package manager versions, not installing dependencies, slow initialization, and poor quality in general
lsp-proxy was complex and no single Sourcegrapher fully understood how lsp-proxy, lsp-adapter, and indexer worked
Aside from Swift, we simply didn’t prioritize work on language servers (partly because of the complexity of lsp-proxy, partly because of other priorities)
Many things have changed in the last year to make it possible to improve language support now:
With Sourcegraph extensions, it’s easier to understand how code intelligence on Sourcegraph works, which makes it easier to build on and all you need to understand is the Sourcegraph extension API (no need to understand xfiles/xcontents, xcache, lsp-adapter, lsp-proxy, etc.) in order to add language support
We’ve learned that it’s fairly easy to patch existing language servers (Go, TypeScript, and Python) to support zip archive fetching and WebSockets. This results in a more maintainable and "pure" language server than wrapping a language server with lsp-adapter.
Based on these learnings, the following principles will guide future improvements:
Prioritize languages by a combination of popularity, ease of analysis, and Sourcegraph customer needs (statically-typed languages, ones that already have solid language servers, ones that customers are asking for, etc.)
Focus on quality over quantity (already tried quantity in 2018 with lsp-adapter and cold emails, and this stagnated)
Fund improvements to language servers if it means language support will improve faster
UI/UX ergonomics matter: suppress non-actionable errors and indicate when some analysis is taking a long time
Sourcegraph believes that there will be one canonical language server per language, and we will be investing effort in the language server that is likely to succeed and become adopted by the respective language community.
We will assess and test language servers roughly on these aspects:
Basic features such as hover tooltips, jump-to-definition, and find-references in simple and popular repositories
Initialization time and response time
Cross-repository code intelligence
Here are the first languages that we plan to put effort towards:
If you're interested in language analysis and want to add language support to Sourcegraph, we want to hear from you! Tweet at @srcgraph. Sourcegraph is willing to sponsor work on language servers and Sourcegraph language extensions, provide technical advice, and gather feedback.