
A source of knowledge for Language Server Protocol implementations - rayascott
https://langserver.org/
======
xg15
I still don't get it. We could create a parser framework that allowed a client
to get some sort of generic AST and reference graph - which would enable all
the use-cases of language servers but would also allow more use-cases in the
future (e.g. IntelliJ-style inspections or language-aware diffs).

Instead, the standard requires running half a dozen processes with an API that
doesn't provide anything except the exact data required for a number of
handpicked use-cases.

Considering that even modern IDEs (again, see IntelliJ for examples) can do
more, I don't see how this is a good way forward.

~~~
zaphar
A generic AST and reference graph that shipped a common denominator of
languages is not as easy to do as a set of common operations and queries

I think you may be underestimating the feasibility of what you propose.

~~~
jblow
You don’t need to do a generic AST. Have it be a protocol ... that runs in-
process via an API. Because you know what, that’s what an API is ... a
protocol for communicating with someone else’s code. But you don’t have to run
extra processes or suffer context switches, and you don’t have to be in the
business of debugging distributed systems in order to accomplish any tiny
thing. Amazing!!!

This whole LSP thing is a mindbogglingly bad idea, brought to you by the same
kinds of thought processes that created the disaster that is today’s WWW.

~~~
klmr
Right, this seems obvious. Any idea why they opted not to go that way?

I guess the reason is that the original use-case was VS Code & TypeScript (?)
and developing a lowest common denominator API for all clients would mean C,
so they would have had to program to a C API even though both the client (VS
Code?) and the server (Node?) are running JavaScript.

But then maybe the answer should be to provide better C invoke wrappers for
high-level languages, not to use HTTP instead of C.

~~~
frou_dh
Knowing programmers, it's probably an absolutely irresistible concept that the
provider for a given language must be easy (in the Hickey-ian sense) to write
entirely in that language.

~~~
zaphar
Not just a concept. Many languages are bootstrapped and therefore the
canonical tools for understanding that languages syntax and semantics are in
that languages stdlib. You would have replicate all of that in your IDE's
language instead. It's DRY at work.

------
tiben_
That's pretty interesting. I use Eclim (vim + eclipse headerless) everyday for
my Java projects. Has someone already tried the Java lang servers, especially
with Vim? How does it compares with Eclim ?

~~~
nerdponx
This is my concern with the LSP. It's a wonderful idea, but its widespread
adoption also implies abandoning many well-liked language-specific tools like
Eclim.

~~~
zaarn
I think it can work hand-in-hand; general support via LSP and tight coupling
with additional augmentation.

~~~
tiben_
I don't know how feasible it is but i agree, it would be a pity to have to
throw away Eclim because of LSP.

------
frou_dh
It's surprising that there's no Go language server with code-completion
support.

Isn't most of the machinery to extract that information from source text
present in the standard library?
[https://golang.org/pkg/go/](https://golang.org/pkg/go/)

~~~
dualogy
There's a couple of popular CLI tools for code-completion and other
"IntelliSense"-ish functionality that are meant to be editor-agnostic --- ie.
"focus on just your editor-specific plugin plumbing and use these proven CLI
tools for the underlying language intelligence".

(I made a list of useful, stably working ones about half a year ago when
hacking on a custom VScode plugin, many but not all of them linters, haven't
looked into latest developments: [https://github.com/metaleap/go-
util/blob/master/dev/go/devgo...](https://github.com/metaleap/go-
util/blob/master/dev/go/devgo.go#L19) )

Just that maybe none have fully implemented LSP. I guess even a from-scratch
Golang LSP implementation might do well to just utilize these tools for
underlying lang intel --- rather than these tools themselves bloating up by
implementing some maybe-just-transient-maybe-the-future current-day MS-backed
protocol.

~~~
frou_dh
I like the plethora of linters. It's generally straightforward to wire up
custom linters and parse file:line:column from their stdout, since that's an
age-old paradigm (overlap from compiler errors).

Code completion has a much higher bar for acceptable UI, though. I trust a
Language Server Client with tons of users/contributors to deliver non-
idiosyncratic UI sooner than MVP UI integrations of specific tools.

A good example of this is "Tern" for JavaScript. It (the backend
indexing/completion engine) is absolutely killer, but the tightly coupled
editor plugin/package just for Tern is decidedly "meh". I suspect because
hardly anyone is developing, or indeed using, that specific integration.

\---

Regardless of the overall merit of the Language Server initiative, the "matrix
vs column" problem they articulate is bang on the money in terms of delivering
quality (non-idiosyncratic) UI.

~~~
dualogy
> _Code completion has a much higher bar for acceptable UI, though. I trust a
> Language Server Client with tons of users /contributors to deliver non-
> idiosyncratic UI sooner than MVP UI integrations of specific tools_

Apt for the client-side. But as for "there's no Go language server"\---

It's still more sensible for a say Golang LSP implementation (the server side)
to rely on the existing `gocode` tool and related tooling as underlying to
deliver auto-completion, than reinvent the wheel here. These have already been
battle-tested and encountered+fixed god-knows-how-many quirks that can occur
when attempting to furnish a most-useful-for-current-cursor-context code
completion.

Which kinda was my point. Anyone is free to wire up a say Golang LSP
implementation without needing to redo all that the exising tooling already
does well. If nobody felt like doing such an LSP server to-date, it's probably
mostly because it's a young protocol still looking to find adoption beyond VS
--- the ole' chicken'n'egg =)

~~~
frou_dh
Hey thanks. You prompted me to look into `gocode` again and I've got it
working a lot better than when I last gave it a shot.

------
zabil
We are in the process of adding full support for language server protocol into
our testing tool [https://github.com/getgauge/gauge-
vscode](https://github.com/getgauge/gauge-vscode) and it's been a great
experience. In the past, we implemented these features for every IDE plugin
(IntelliJ, Eclipse, Visual Studio) and it's tough to build, test or debug.
With language server, we build all these features in our tools language i.e.
Golang, and it works for any IDE that supports the protocol.

------
hammerandtongs
Notably and regrettably absent is Kotlin -

[https://discuss.kotlinlang.org/t/any-plan-for-supporting-
lan...](https://discuss.kotlinlang.org/t/any-plan-for-supporting-language-
server-protocol/2471)

Java seems usefully far along however...

~~~
teddyuk
i wonder if this is a symptom of having a tools vendor (who only makes money
via tools) create a language?

~~~
chubot
I suspect that they have a lot of bells in whistles in IntelliJ that are not
possible over the language server protocol. But yes it from a business
perspective it doesn't make much sense to devote a lot of manpower to making
competitors more capable.

~~~
cwyers
Microsoft seems to currently be investing a lot of effort in making developing
.NET server apps on a competitor's platform more capable, so I think it's not
as cut and dried as that. If you develop a "good enough" LSP server for
Kotlin, and have the "best of breed" tools in IntelliJ, then you potentially
increase the pool of Kotlin developers, which creates network effects making
Kotlin development more appealing, and then you see more IntelliJ use. There
can be benefits to making your platform play well with your competitors, if
you can still monetize the platform.

