Hacker News new | past | comments | ask | show | jobs | submit login

So, what is the difference in responsibility from the Language Server Protocol that Visual Studio Code uses? I get that they’re riffing on the same concept, but why separate the two? What’s the difference, other than that “oh this one is more build-y”?



LSP is specialised for static analysis of code, and aims to provide a generic protocol for doing that. However, say I want to run a single test from Vim. Currently I have, for ruby, rspec.vim so ",s" will run the test under the cursor, but all it does is shell out to an rspec command. So it seems the idea is to provide a generic interface for "run this test in this project", or "build this file", without having to care about the specific build tooling involved.

I like it as an idea. We'll see if it gets any traction outside of Scala-land.


The main difference between the two is that BSP serves the needs of language servers and LSP serves the needs of editors. The two protocols have some duplicated functionality like build/publishDiagnostics (== LSP textDocument/publishDiagnostics), build/logMessage (== LSP window/logMessage), build/showMessage (== LSP window/showMessage), build/didChangeWatchedFiles (== LSP workspace/didChangeWatchedFiles).

There are some methods in BSP that might merit inclusion in LSP like buildTarget/test and buildTarget/run.

However, there are some critical methods in BSP that make no sense in LSP like buildTarget/scalacOptions. This is a method to extract dependencies and other compiler flags that are necessary for a Scala language server to provide completions, navigation, etc. Currently, every Scala IDE builds its own "export" command for each supported build tool resulting in duplicated effort. With BSP, we hope that a build tool can implement the server once and in return get integrations for multiple IDEs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: