Sourcegraph CEO here. Thanks for posting this. Happy to answer any questions!
What is the relationship between Sourcegraph and the LSP? The Master Plan reads like you were part of creating it?
Sourcegraph Master Plan
11–20 of 37 posts
Re: Sourcegraph Master Plan
#12I don't get what problem this solves that Emacs with appropriate language modes doesn't already solve.
Sourcegraph CEO here. I have been a near-daily Emacs user for 15+ years. The unsolved problem for you and me as Emacs users is this: I wish I had the same high-quality extensions that VS Code users get. I use VS Code 1/3 of the time because the editing experience is so much better in many languages (such as TypeScript).
Have you tried VS Code? I would highly recommend you try it if you haven't yet. I think you'll see what you are missing.
(Of course, Emacs has many awesome features/modes that other editors lack, too. The same principle applies there.)
Re: Sourcegraph Master Plan
#13Sourcegraph CEO here. Thanks for posting this. Happy to answer any questions!
What is the relationship between Sourcegraph and the LSP? The Master Plan reads like you were part of creating it?
Sourcegraph CEO here. Microsoft designed and released LSP. We are eternally grateful for that! We played no part in its creation. The first LSP mention links to the repo at https://github.com/Microsoft/language-server-protocol with more info.
We have, however, built and/or sponsored many language servers. (Those, in turn, build on compiler APIs that other people tirelessly created, to which we also owe thanks.)
Re: Sourcegraph Master Plan
#14Earlier quoted context omitted.
What is the relationship between Sourcegraph and the LSP? The Master Plan reads like you were part of creating it?
Sourcegraph CEO here. Microsoft designed and released LSP. We are eternally grateful for that! We played no part in its creation. The first LSP mention links to the repo at https://github.com/Microsoft/language-server-protocol with more info. We have, however, built and/or sponsored many language servers. (Those, in turn, build on compiler APIs that other people tirelessly created, to which we also owe thanks.)
The LSP is a really wonderful, simple and well executed idea. The simplicity of the protocol, cross platform (not bound to a COM interface or similar Windows only technology), ease of creation of an implementation in any language, all well done.
This is where the deep experience of Microsoft in building developer tools together with the desire to be cross platform are shining.
As a user of Emacs under Linux for the past 20 years to code in Fortran, they succeed in me using Visual Studio Code[0] and hack into a Fortran Language Server!
[0]: https://www.ceondo.com/ecte/2018/09/vscode-visual-studio-cod...
Re: Sourcegraph Master Plan
#15Sourcegraph CEO here. Thanks for posting this. Happy to answer any questions!
How much of this plan do you envision will be provided by Sourcegraph and how much comes from the many other people working on similar things? (For example, many people are working on language servers these days.)
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 because 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.
Re: Sourcegraph Master Plan
#16Earlier quoted context omitted.
Sourcegraph CEO here. Microsoft designed and released LSP. We are eternally grateful for that! We played no part in its creation. The first LSP mention links to the repo at https://github.com/Microsoft/language-server-protocol with more info. We have, however, built and/or sponsored many language servers. (Those, in turn, build on compiler APIs that other people tirelessly created, to which we also owe thanks.)
The LSP is a really wonderful, simple and well executed idea. The simplicity of the protocol, cross platform (not bound to a COM interface or similar Windows only technology), ease of creation of an implementation in any language, all well done. This is where the deep experience of Microsoft in building developer tools together with the desire to be cross platform are shining. As a user of Emacs under Linux for the p…
Yes, and LSP is one of those ideas that I respect even more because it was laughed at initially! Unlike most other approaches at solving this problem, it did NOT try to model concepts or structures in programming languages. It is presentational, not semantic; it is solely concerned with "what does the user want to do/see". It was radically simpler than other approaches at solving the same problem, and it has achieved tremendous adoption, so I think it's fair to say it's a success.
BTW, very cool that you built the Fortran language server!
Re: Sourcegraph Master Plan
#17Sourcegraph CEO here. Thanks for posting this. Happy to answer any questions!
Looks awesome and I hope to hear from succeed! The blue box half way down is really bad on mobile. Too much margin. edit: https://imgur.com/a/8vCwBjh
Thanks for pointing that out. Fix deployed, should be online in a few min.
Re: Sourcegraph Master Plan
#18Earlier quoted context omitted.
The LSP is a really wonderful, simple and well executed idea. The simplicity of the protocol, cross platform (not bound to a COM interface or similar Windows only technology), ease of creation of an implementation in any language, all well done. This is where the deep experience of Microsoft in building developer tools together with the desire to be cross platform are shining. As a user of Emacs under Linux for the p…
Yes, and LSP is one of those ideas that I respect even more because it was laughed at initially! Unlike most other approaches at solving this problem, it did NOT try to model concepts or structures in programming languages. It is presentational, not semantic; it is solely concerned with "what does the user want to do/see". It was radically simpler than other approaches at solving the same problem, and it has achieved…
Simplicity is hard to achieve!
I am not the author of the Fortran Language Server, just fixing bugs and trying to improve it. But as the protocol is simple, this makes the work to improve it also way simpler. This is the part where I am now sure that the LSP will take over the world for the benefits of all the code editors, closed or open source, cross platform or not. And this is good for us as programmers :)
Re: Sourcegraph Master Plan
#19I don't get what problem this solves that Emacs with appropriate language modes doesn't already solve.
Sourcegraph CEO here. I have been a near-daily Emacs user for 15+ years. The unsolved problem for you and me as Emacs users is this: I wish I had the same high-quality extensions that VS Code users get. I use VS Code 1/3 of the time because the editing experience is so much better in many languages (such as TypeScript). Have you tried VS Code? I would highly recommend you try it if you haven't yet. I think you'll see…
What the point in using VS Code compared to emacs when we have LSP servers and an emacs lsp-mode ?
Re: Sourcegraph Master Plan
#20Earlier quoted context omitted.
Sourcegraph CEO here. I have been a near-daily Emacs user for 15+ years. The unsolved problem for you and me as Emacs users is this: I wish I had the same high-quality extensions that VS Code users get. I use VS Code 1/3 of the time because the editing experience is so much better in many languages (such as TypeScript). Have you tried VS Code? I would highly recommend you try it if you haven't yet. I think you'll see…
What the point in using VS Code compared to emacs when we have LSP servers and an emacs lsp-mode ?
VS Code extensions for language support are (usually) a combo of a language server plus VS Code extension code. Other editors using just the language server won't get the features implemented in the VS Code extension. So Emacs lsp-mode and a language server won't get you all the features that VS Code users enjoy.
For example, the Go language server (if enabled) in vscode-go is only responsible for hovers, definitions, references, and a few other things. Auto-imports, code lens for tests, helpful commands, coverage, etc., are all implemented in vscode-go's TypeScript extension code.
I recommend just trying VS Code for the languages you use in Emacs to see what you're missing. I bet a blog post about your experience would get to the front page of HN. :)
(One solution, of course, is to make it possible to write all of those things in a way that can be consumed by all editors. Check out https://github.com/sourcegraph/sourcegraph-extension-api to see our work to let you write any kind of editor extension in an editor-independent way (not just the language/code intelligence features). When this gets into beta, we'll feel comfortable updating this master plan to denote the progress toward the goals.)