Hacker News Reader

Comment by georgewfraser | Hacker News Reader

The language server protocol is revolutionary for providing features like intelligent autocomplete to text editors. It basically brings proper separation-of-concerns to language tooling. In particular, because it's based on JSON messages over sockets, you can implement the tooling for each language in that language. I'm the author of https://github.com/georgewfraser/vscode-javac which uses the Java compiler tree API to implement a Java language server---the task was made radically easier by being able to implement it in the target language.

View on HN

> The language server protocol is revolutionary for providing features like intelligent autocomplete to text editors.

There have been similar things recently. Jetbrains built an out-of-process version of resharper in order to power Rider.

https://www.jetbrains.com/rider/

Omnisharp, which is aimed at providing features like autocomplete to various text editors, has done out-of-process as well: https://github.com/OmniSharp/omnisharp-server

Language server protocol is a specification, hopefully all tools will work towards compatibility:

https://github.com/Microsoft/language-server-protocol

> Language server protocol is a specification

This is indeed the important bit, and out of process is in that regard merely a implementation detail (although a practical one).

Right now we have a situation where the N editors and M languages gives us NxM language-plugins matrix if we want complete support.

If a new editor or language comes along, the job to implement complete support across the line is astronomical (thus noone does). Right now you may even have to switch editor to get "full" support for a given language, if any support at all.

LSP replaces this with a much more manageable situation where we have N editors (with LSP clients) + M languages (with LSP servers), and that yielding a N clients + M servers solution-space instead.

Simplified a wee bit: One new editor only needs to implement a single LSP-client to support all languages with a LSP-server, and one new language only need to implement a single LSP-server to be supported in all editors which already has a LSP-client.

This really is a revolutionary change, and I'm surprised how little attention LSP has gotten in the grand scheme of things.

Not to knock the Jetbrains Team, but I'd like to see them more excited about the language server protocol. It has the potential to give me a much better default minimum level of support for so many more programming languages that their IDEs would be even More useful to me. Which is good for them. I don't expect them to instantly support things like Rust, or Erlang or Elixir, but I don't expect them to make it any harder for others to suppose these things.

Hopefully they start talking about adding support soon. It's just too good not to.

There were a couple of comments and Reddit threads about this by Alexsey Kladov, one of the maintainer of the Rust plugin for IDEA:

https://github.com/intellij-rust/intellij-rust/issues/964#is...

https://www.reddit.com/r/rust/comments/5rhqj0/ide_compiler_h...

Basically, it's harder than one thinks. Interesting also to note that he believes that Dart's analysis-server design is a stronger and more complete one than the RLS-one in Typescript (he also gives reasons for this statement).

Wasn't OmniSharp also started by Microsoft? Not sure about it, but I think it was.

Looking at the team http://www.omnisharp.net/#team the majority of them are not Microsoft employees (exceptions include Scott Hanselman and Rajkumar Janakiraman) So I don't think so.

Iirc Omnisharp comes from the Mono/Xamarin-team and is used as the backing technology behind Monodevelop/Xamarin Studio.

This blog post (scroll down to "Microsoft & OSS") details how the project came to be. http://blog.jonathanchannon.com/2014/11/12/csharp-first-clas...

Hi! tldr; It was completely an OSS project to start with and MS wanted to get on-board which was great.

I started on my own "multi-language/multi-editor" (potentially) out-of-process "language server" (sans an established protocol) in Go (json over pipes because who needs sockets) as the MS-initiated LSP was and it seems remains very much in flight and in flux, still evolving. Once it matures and a fair number of other editors adopt it (to lend it long-term viability), I'd probably switch said backend process from custom-hodge-podge-protocol to that standard.

Of course the motivation here was to begin building out something I can easily extend to other editors and languages over the years to come as I noticed after some 15+ years that one switches out both editors and languages not-frequently-but-recurringly over a longer timeframe. At some point I assessed Sublime as abandoned and VScode as pretty damn hot, but the real lesson here of course is that some independence from one player's to-be-neglected-in-the-future tooling and/or protocols is .. pleasant. In the same vain, when I do switch I won't have to switch from a dozen 3rd-party nodejs-"powered" extensions to a dozen 3rd-party python-"powered" extensions but can just script up one lean frontend shim from the editor's extensibility API to the actual meat furnished by said Go-powered backend.

Bit of a funky concept. It really started out as "this is gonna be a weekend effort, heck I just run existing 3rd-party tooling command-line processes and pipe their results back over json sanitized and somewhat processed". Enter countless intricacies and we're talking a real code-base even for something initially-apparently utterly trivial and one-off! All the better to attack it once, in full.

Reply on news.ycombinator.com