5 ms·

Langserver.org – A community-driven source for Language Server implementations

131 points by gitgud 7y ago

st3fan 7y ago
THe SourceGraph server for Go is deprecated in favor of 'gopls'. This is documented on the sourcegraph github page.
- aphistic 7y ago
  It's interesting that langserver.org is actually run by SourceGraph and it's still out of date.
- guessmyname 7y ago
  The website is maintained by SourceGraph so of course there’s going to be some bias. That being said, the website is editable on GitHub [1] so people can submit fixes if needed. I’ve been using “gopls” [2] since Feb 2019 and I’m very happy with the functionality. Rebecca Stambler, Heschi Kreinick, Muir Manders and the rest of the team are doing a wonderful job. I encourage everyone to join the #gopls channel in the Gophers Slack group [3] to follow the updates. [1] https://github.com/langserver/langserver.github.io https://github.com/langserver/langserver.github.io [2] https://github.com/golang/tools/tree/master/gopls https://github.com/golang/tools/tree/master/gopls [3] https://invite.slack.golangbridge.org/ https://invite.slack.golangbridge.org/
  - sqs 7y ago
    Sourcegraph CEO here. We fixed it and added gopls. Sorry for the mistake. It is not bias. We are very happy that Google made gopls. It is not our core product (universal code search is), and Google building gopls means we can focus more on our product. :)
_bxg1 7y ago
Quick piece of feedback: the big table with all the languages could use a color other than red (gray?) for "Not Applicable". For example, I assume that's the reason JSON is missing "Jump to def", "Find references", etc.
dang 7y ago
A thread from 2017: https://news.ycombinator.com/item?id=15711604 https://news.ycombinator.com/item?id=15711604
josteink 7y ago
I have to say that list has gotten waaay longer since last time I saw it. LSP really has been a massive success, and despite being made by MS, has been one of the main reasons I’ve been able to keep using Emacs and not migrated to other more IDE-like editors. MS deserves som serious credit here for being one of the few players willing to think in protocols these days. Protocols vs products makes a big difference.
- _bxg1 7y ago
  It's truly one of those I-can't-believe-nobody-thought-of-this-before ideas. And beyond the obvious benefits to developers' experience, it's also a huge boon to smaller language projects. If you build a new, open language and don't have the backing of a huge company, you definitely don't have the resources to integrate it directly with every editor someone might want to write it in. But you might be able to put together a single language-server.
  - mikewhy 7y ago
    There was (and still is) YouCompleteMe for Vim, which is the idea of a code-completion server with editor plugins, so it's definitely a thing people had thought of. Microsoft really took the ball and ran with it, and I'm very grateful for that.
  - charlieflowers 7y ago
    I think Slime for Emacs was the first to think of it, a looong time ago (at least it was the first place I saw the idea in action). Edit to clarify -- Slime was never meant for general use across many languages. But Slime had the "smarts" in a separate process and communicated with the editor via the network.
  - LessDmesg 7y ago
    I know I'm making an LSP implementation for my personal language. A total must-have.
- int_19h 7y ago
  While we're at it, there's a similar, albeit lower-key, effort for debuggers: https://microsoft.github.io/debug-adapter-protocol/specification https://microsoft.github.io/debug-adapter-protocol/specifica... One example of use outside of Microsoft products: https://github.com/puremourning/vimspector https://github.com/puremourning/vimspector
The_rationalist 7y ago
Where can I found a feature comparison of state of the art LSPs vs intellij idea features? What can one do that the other cannot?
sytse 7y ago
It seems that Language Server Index Format (LSIF) https://code.visualstudio.com/blogs/2019/02/19/lsif https://code.visualstudio.com/blogs/2019/02/19/lsif is the successor to the Language Server Protocol (LSP). LSIF supports code navigation without having all source code files available on a local disk like LSP requires.
- kdmarrett 7y ago
  Good to know thank you
- mikewhy 7y ago
  Maybe "successor" isn't the right word, as per the linked article: > The goal of the Language Server Index Format is to augment the LSP protocol
  - sytse 7y ago
    Thanks for making that clear.
  - lostintangent 7y ago
    Correct! We designed LSIF to be a complement to LSP. LSIF is basically a way to persist language server state, so that LSP queries (e.g. what are the definitions for this symbol?) can be answered without needing an active LSP server running. Among other things, LSIF enables rich IDE navigations on remote codebases, where’s its much more scalable to perform those queries using indexed data vs. spinning up language servers. Here’s the blog post where we first announced the work we were doing, that led to the creation of LSIF: https://code.visualstudio.com/blogs/2018/12/04/rich-navigation https://code.visualstudio.com/blogs/2018/12/04/rich-navigati....
- slimsag 7y ago
  At Sourcegraph we are also running an identical website but for tracking LSIF indexers :) https://lsif.dev https://lsif.dev
mikewhy 7y ago
Another thing I really like about LSP is that formatting and linting are built-in concepts. Using something like https://github.com/iamcco/diagnostic-languageserver https://github.com/iamcco/diagnostic-languageserver you can bridge existing command-line tools that only support stdio into your editor of choice.
- realharo 7y ago
  It is still missing semantic highlighting (e.g. a local variable has a different color than a function parameter), although looks like things are finally moving on that front. https://github.com/microsoft/language-server-protocol/issues/18 https://github.com/microsoft/language-server-protocol/issues...
bobajeff 7y ago
It's cool that Kate almost has full support for LSP. Update: here's a post I've found about it: https://kate-editor.org/post/2020/2020-01-01-kate-lsp-client-status/ https://kate-editor.org/post/2020/2020-01-01-kate-lsp-client... I'd love for Geany to also either get support built-in or as a plug-in. Also noteworthy is CodeMirror and JupyterLab working on support.
mthoms 7y ago
Given this, I wonder what the future holds for JetBrains. They've made a good business out of providing standalone solutions for the more popular languages.
- stefan_ 7y ago
  The same thing as always, making kick ass IDEs and actually working, robust productivity tools? A few rows down someone is praising "language servers" as some sort of Einstein discovery. I'd argue that was the easy part and they are rapidly learning about the difficulties involved, and the way is paved with auto-generated configuration pages wrapping json.
- 65464guityi89 7y ago
  I haven't seen a paid language server, but I would be willing to pay for a fully featured, plug-&-play server with installation instructions for common editors. Maybe they could pull some of their tools out of their IDEs and into a server?
- cube2222 7y ago
  Indeed, and so far for the languages I’ve used, the level of support and refactorings surpassed anything presented by open source tools. Additionally, they provide a uniform editing experience for a load of languages, which is one of the things I love the most. Where you’re writing go, python, java m, cpp or rust, the refactorings work similarly. (I am kind of a fanboy)

131 points by gitgud 7y ago

st3fan 7y ago

THe SourceGraph server for Go is deprecated in favor of 'gopls'. This is documented on the sourcegraph github page.

aphistic 7y ago
It's interesting that langserver.org is actually run by SourceGraph and it's still out of date.
guessmyname 7y ago
The website is maintained by SourceGraph so of course there’s going to be some bias. That being said, the website is editable on GitHub [1] so people can submit fixes if needed. I’ve been using “gopls” [2] since Feb 2019 and I’m very happy with the functionality. Rebecca Stambler, Heschi Kreinick, Muir Manders and the rest of the team are doing a wonderful job. I encourage everyone to join the #gopls channel in the Gophers Slack group [3] to follow the updates. [1] https://github.com/langserver/langserver.github.io https://github.com/langserver/langserver.github.io [2] https://github.com/golang/tools/tree/master/gopls https://github.com/golang/tools/tree/master/gopls [3] https://invite.slack.golangbridge.org/ https://invite.slack.golangbridge.org/
- sqs 7y ago
  Sourcegraph CEO here. We fixed it and added gopls. Sorry for the mistake. It is not bias. We are very happy that Google made gopls. It is not our core product (universal code search is), and Google building gopls means we can focus more on our product. :)

_bxg1 7y ago

Quick piece of feedback: the big table with all the languages could use a color other than red (gray?) for "Not Applicable". For example, I assume that's the reason JSON is missing "Jump to def", "Find references", etc.

dang 7y ago

A thread from 2017: https://news.ycombinator.com/item?id=15711604 https://news.ycombinator.com/item?id=15711604

josteink 7y ago

I have to say that list has gotten waaay longer since last time I saw it. LSP really has been a massive success, and despite being made by MS, has been one of the main reasons I’ve been able to keep using Emacs and not migrated to other more IDE-like editors. MS deserves som serious credit here for being one of the few players willing to think in protocols these days. Protocols vs products makes a big difference.

_bxg1 7y ago
It's truly one of those I-can't-believe-nobody-thought-of-this-before ideas. And beyond the obvious benefits to developers' experience, it's also a huge boon to smaller language projects. If you build a new, open language and don't have the backing of a huge company, you definitely don't have the resources to integrate it directly with every editor someone might want to write it in. But you might be able to put together a single language-server.
- mikewhy 7y ago
  There was (and still is) YouCompleteMe for Vim, which is the idea of a code-completion server with editor plugins, so it's definitely a thing people had thought of. Microsoft really took the ball and ran with it, and I'm very grateful for that.
- charlieflowers 7y ago
  I think Slime for Emacs was the first to think of it, a looong time ago (at least it was the first place I saw the idea in action). Edit to clarify -- Slime was never meant for general use across many languages. But Slime had the "smarts" in a separate process and communicated with the editor via the network.
- LessDmesg 7y ago
  I know I'm making an LSP implementation for my personal language. A total must-have.
int_19h 7y ago
While we're at it, there's a similar, albeit lower-key, effort for debuggers: https://microsoft.github.io/debug-adapter-protocol/specification https://microsoft.github.io/debug-adapter-protocol/specifica... One example of use outside of Microsoft products: https://github.com/puremourning/vimspector https://github.com/puremourning/vimspector

The_rationalist 7y ago

Where can I found a feature comparison of state of the art LSPs vs intellij idea features? What can one do that the other cannot?

sytse 7y ago

It seems that Language Server Index Format (LSIF) https://code.visualstudio.com/blogs/2019/02/19/lsif https://code.visualstudio.com/blogs/2019/02/19/lsif is the successor to the Language Server Protocol (LSP). LSIF supports code navigation without having all source code files available on a local disk like LSP requires.

kdmarrett 7y ago
Good to know thank you
mikewhy 7y ago
Maybe "successor" isn't the right word, as per the linked article: > The goal of the Language Server Index Format is to augment the LSP protocol
- sytse 7y ago
  Thanks for making that clear.
- lostintangent 7y ago
  Correct! We designed LSIF to be a complement to LSP. LSIF is basically a way to persist language server state, so that LSP queries (e.g. what are the definitions for this symbol?) can be answered without needing an active LSP server running. Among other things, LSIF enables rich IDE navigations on remote codebases, where’s its much more scalable to perform those queries using indexed data vs. spinning up language servers. Here’s the blog post where we first announced the work we were doing, that led to the creation of LSIF: https://code.visualstudio.com/blogs/2018/12/04/rich-navigation https://code.visualstudio.com/blogs/2018/12/04/rich-navigati....
slimsag 7y ago
At Sourcegraph we are also running an identical website but for tracking LSIF indexers :) https://lsif.dev https://lsif.dev

mikewhy 7y ago

Another thing I really like about LSP is that formatting and linting are built-in concepts. Using something like https://github.com/iamcco/diagnostic-languageserver https://github.com/iamcco/diagnostic-languageserver you can bridge existing command-line tools that only support stdio into your editor of choice.

realharo 7y ago
It is still missing semantic highlighting (e.g. a local variable has a different color than a function parameter), although looks like things are finally moving on that front. https://github.com/microsoft/language-server-protocol/issues/18 https://github.com/microsoft/language-server-protocol/issues...

bobajeff 7y ago

It's cool that Kate almost has full support for LSP. Update: here's a post I've found about it: https://kate-editor.org/post/2020/2020-01-01-kate-lsp-client-status/ https://kate-editor.org/post/2020/2020-01-01-kate-lsp-client... I'd love for Geany to also either get support built-in or as a plug-in. Also noteworthy is CodeMirror and JupyterLab working on support.

mthoms 7y ago

Given this, I wonder what the future holds for JetBrains. They've made a good business out of providing standalone solutions for the more popular languages.

stefan_ 7y ago
The same thing as always, making kick ass IDEs and actually working, robust productivity tools? A few rows down someone is praising "language servers" as some sort of Einstein discovery. I'd argue that was the easy part and they are rapidly learning about the difficulties involved, and the way is paved with auto-generated configuration pages wrapping json.
65464guityi89 7y ago
I haven't seen a paid language server, but I would be willing to pay for a fully featured, plug-&-play server with installation instructions for common editors. Maybe they could pull some of their tools out of their IDEs and into a server?
cube2222 7y ago
Indeed, and so far for the languages I’ve used, the level of support and refactorings surpassed anything presented by open source tools. Additionally, they provide a uniform editing experience for a load of languages, which is one of the things I love the most. Where you’re writing go, python, java m, cpp or rust, the refactorings work similarly. (I am kind of a fanboy)