This is great! Abstracting away static code analysis is very helpful for people like us building browser based dev tools.
I am the developer of HiveMind (crudzilla.com), I have been dragging my feet about plunging into static code analysis so this type of solution is definitely intriguing.
I'm on the fence about this, standardization let's people pool resources to provide common functionality, but it also ossifies the interface so that doing anything not supported by the interface becomes harder than before.
The first thing that pops into my head is that for languages with interprocedural type inference, I really want my IDE to show me what types it has inferred, but this is outside the spec and not even applicable to all languages.
With this,a new language can have an IDE integration done easily which can cover say 95% features. Some language specific feature may be obviously left out but getting a minimum viable integration to any supported IDE is a good thing.May be when this protocol evolves,it can give extension to the protocols to cover the other 5% features(or may be it is already there)
Are there any examples of extensible protocols like this in the wild? I'm asking because the only such protocol that seems to get mentioned on HN is XMPP (and always with groans).
Heh. We'll see. Writing the glue code is not what makes writing language analysis hard. This is clearly a move to make the lives of IDE writers easier, rather than those who would be writing the analysis code.
But it'd make your analysis code work for multiple IDEs and editors instead of having to learn about each's peculiarities. One less thing to worry about is always good.
There are many ways to go about, but it could be easily achieved with any diagramming or graphics application. For example, LibreOffice Draw or Microsoft Visio.
I only glanced through the document, but I didn't see anything which could verify that the "Tool" and the "Language Server" are both referring to the same content. Is there a mechanism for handling this kind of synchronization drift?
The "server" in "language server" does not mean "server you access over the network" but "other process (on your machine) your editor talks to". (This is just the spec for a protocol.)
Can it be on across the internet? So, Apple can or cannot set up an internet service for Swift? If I think I have a better version can I point my editor towards that? If I program in a couple of languages, do I need to get ahold of servers to install?
To answer your points in order: No reason it couldn't talk across the Internet, I guess, if you're comfortable sending your source code to whoever is running the server and dealing with network latency on your autocomplete. Yes, you could easily point your editor to a different server, this protocol is basically just an API spec. And lastly, yes, you would (likely) need a different server for each of your languages - this project just provides a way to let an IDE implement one API client that can be used with each different language's tools.
> To answer your points in order: No reason it couldn't talk across the Internet, I guess, if you're comfortable sending your source code to whoever is running the server and dealing with network latency on your autocomplete.
I'm thinking as part of a remote learning class. I'm pretty comfortable that it wouldn't violate any student privacy rules.
In theory, yes the protocol can be used across the internet, but that would raise plenty of issues (security being a huge one). This is designed so that any program, like an IDE, can get code analysis and more without having to build special handling for each of them.
> So, Apple can or cannot set up an internet service for Swift?
Again, in theory they could. But why would they do that? Just run the server locally and get all the information there.
> If I think I have a better version can I point my editor towards that?
Yes. You simply stop the currently running language server and start the one you want to use instead.
> If I program in a couple of languages, do I need to get ahold of servers to install?
Yes. Each language would, in theory, provide its own server to do analysis. Of course, your favorite IDE would likely be more than happy to start the server for you if it's not running yet (as it's just a small process that runs in the background).
If you want to see how this works in practice just grab Visual Studio Code and start editing a Typescript file. This is already in use there.
> In theory, yes the protocol can be used across the internet, but that would raise plenty of issues (security being a huge one). This is designed so that any program, like an IDE, can get code analysis and more without having to build special handling for each of them.
I'm pretty sure I would be ok at part of teaching a class.
> Again, in theory they could. But why would they do that? Just run the server locally and get all the information there.
I was getting at that from the student-level. I'm pretty sure some metrics on edge problems in a remote learning class might help with the material revisions.
We're considering moving the new Rust language service over to this protocol, or possibly, having it as a default protocol while supporting other protocols.
Since I've been learning it recently, maybe some points to help understand it:
It's just the protocol piece. Currently, VSCode will stand up the language server and communicate using the protocol over stdin/stdout. Nothing to say they couldn't support http servers in the future, but currently it seems lower level that that.
They do support hovers, which you can use for seemingly anything. We currently are using them for type information and showing API docs.
I'm hoping this takes on with other editors, as once they support it, then they'll get the stronger language support the servers provide, which can do hovers, on-the-fly error checking, code navigation, and more. It's not perfect, but as a baseline set of features, it's a pretty good starting set.
30 comments
[ 0.22 ms ] story [ 68.1 ms ] threadI am the developer of HiveMind (crudzilla.com), I have been dragging my feet about plunging into static code analysis so this type of solution is definitely intriguing.
The first thing that pops into my head is that for languages with interprocedural type inference, I really want my IDE to show me what types it has inferred, but this is outside the spec and not even applicable to all languages.
(I don't disagree with your general point, just curious about this specific example)
Which requires explicit UI work, which this protocol won't support.
This actually sounds an awful lot like what Grok was trying to do. Any relation in the development?
I'm thinking as part of a remote learning class. I'm pretty comfortable that it wouldn't violate any student privacy rules.
In theory, yes the protocol can be used across the internet, but that would raise plenty of issues (security being a huge one). This is designed so that any program, like an IDE, can get code analysis and more without having to build special handling for each of them.
> So, Apple can or cannot set up an internet service for Swift?
Again, in theory they could. But why would they do that? Just run the server locally and get all the information there.
> If I think I have a better version can I point my editor towards that?
Yes. You simply stop the currently running language server and start the one you want to use instead.
> If I program in a couple of languages, do I need to get ahold of servers to install?
Yes. Each language would, in theory, provide its own server to do analysis. Of course, your favorite IDE would likely be more than happy to start the server for you if it's not running yet (as it's just a small process that runs in the background).
If you want to see how this works in practice just grab Visual Studio Code and start editing a Typescript file. This is already in use there.
I'm pretty sure I would be ok at part of teaching a class.
> Again, in theory they could. But why would they do that? Just run the server locally and get all the information there.
I was getting at that from the student-level. I'm pretty sure some metrics on edge problems in a remote learning class might help with the material revisions.
Since I've been learning it recently, maybe some points to help understand it:
It's just the protocol piece. Currently, VSCode will stand up the language server and communicate using the protocol over stdin/stdout. Nothing to say they couldn't support http servers in the future, but currently it seems lower level that that.
They do support hovers, which you can use for seemingly anything. We currently are using them for type information and showing API docs.
I'm hoping this takes on with other editors, as once they support it, then they'll get the stronger language support the servers provide, which can do hovers, on-the-fly error checking, code navigation, and more. It's not perfect, but as a baseline set of features, it's a pretty good starting set.