Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Language Server Protocol

github.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: Language Server Protocol

#21

Post by Etzos »

protomyth wrote: post #17
killercup wrote: post #16

Earlier quoted context omitted.

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?

> Can it be on across the internet?

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.

Re: Language Server Protocol

#22

Post by protomyth »

Arcsech wrote: post #20
protomyth wrote: post #17

Earlier quoted context omitted.

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 -…

> 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.

Re: Language Server Protocol

#23

Post by protomyth »

Etzos wrote: post #21
protomyth wrote: post #17

Earlier quoted context omitted.

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?

> Can it be on across the internet? 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…

> 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.

Re: Language Server Protocol

#24

Post by euyyn »

Eridrus wrote: post #14
hitr wrote: post #4

Earlier quoted context omitted.

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)

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.

Re: Language Server Protocol

#25

Post by [deleted] »

avita1 wrote: post #11
hitr wrote: post #4

Earlier quoted context omitted.

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).

[deleted]

Re: Language Server Protocol

#26

Post by [deleted] »

Eridrus wrote: post #14
hitr wrote: post #4

Earlier quoted context omitted.

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)

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.

[deleted]

Re: Language Server Protocol

#27

Post by qwertyuiop924 »

lann wrote: post #18
qwertyuiop924 wrote: post #12

Well, us emacs users will finally get some decent autocomplete. So that's nice, I suppose. This actually sounds an awful lot like what Grok was trying to do. Any relation in the development?

See Kythe (Google OSS): http://kythe.io/

Heh. Neat.

Re: Language Server Protocol

#28

Post by riffraff »

Eridrus wrote: post #3

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 ev…

wouldn't inferred types fit into the "Diagnostic" interface? There are both "info" and "hint" levels which seem appropriate.

(I don't disagree with your general point, just curious about this specific example)

Re: Language Server Protocol

#29

Post by jntrnr »

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.

Post reply on HN