[HN Gopher] LSP: The Good, the Bad, and the Ugly
___________________________________________________________________
LSP: The Good, the Bad, and the Ugly
Author : bryjnar
Score : 112 points
Date : 2024-09-03 23:17 UTC (2 days ago)
(HTM) web link (www.michaelpj.com)
(TXT) w3m dump (www.michaelpj.com)
| oblio wrote:
| Rabbit hole warning (started by the article linked above):
|
| https://matklad.github.io/2022/04/25/why-lsp.html
|
| https://matklad.github.io/2023/10/12/lsp-could-have-been-bet...
| sestep wrote:
| That 2022 post is amazing, thanks for the link!
| matklad wrote:
| And
|
| https://rust-analyzer.github.io/blog/2020/07/20/three-archit...
|
| Is a must-read if you are to build your own LSP server!
| aidenn0 wrote:
| RE: "Not a truly open project."
|
| If LSP isn't truly open, then neither are most GNU projects. It
| was very common for the first 15+ years of GNU's existence for
| the public development process of a project to be "the single
| maintainer publishes a release archive whenever they feel like
| it"
|
| It's a standard freely published and available for all to
| implement. If that's not "truly open" then we have moved the
| goalposts way too far.
| aithrowaway1987 wrote:
| But that is not the standard for current GNU projects in large
| part because of all the easily avoidable friction. "If it was
| good enough for Richard Stallman in 1987, it's good enough for
| Microsoft in 2024" is just a dumb argument.
|
| Not to mention you're conflating apples with oranges, since a
| software _standard_ is very different from an _application._
| POSIX wasn 't just one Bell Labs employee working by himself.
|
| From the article:
|
| > The LSP should be an open standard, like HTTP, with an open
| committee that represents the large community which is invested
| in LSP, and can offer their insight in how to evolve it.
|
| There is no goalpost moving here.
| cryptonector wrote:
| Building and maintaining a community is hard work. Even just
| talking to all comers is hard work. You need a team for that,
| but if you're a team of one then the community is likely
| going to suffer. You could find external contributors to
| promote to committers, but that's work too, and maybe LSP's
| maintainer doesn't want that (or maybe LSP's maintainer's
| employer (MSFT) doesn't want that). Apart from what MSFT
| wants, the rest is just as likely to happen for small enough
| projects whether they be GNU projects or not.
| leni536 wrote:
| Most GNU projects are typically not standards/specifications
| but programs and libraries. That's a significant difference
| IMO.
| kayodelycaon wrote:
| Yeah... this is can be confusing. "Open source", "open
| standard", and "open project" are different concepts.
|
| The first two are well-defined and LSP meets the criteria for
| both.
|
| "Open project" doesn't have a definition or criteria. In this
| case, it probably means the community using a standard,
| controls the standard. The http protocol is an example of this.
|
| Ultimately, they think the people in charge of the project are
| not listening to the people using it. This is a serious
| concern.
|
| However, making a project "open" does not fix this problem. See
| systemd.
|
| I hate dropping Wikipedia links but here is open standard:
| https://en.m.wikipedia.org/wiki/Open_standard
| kelnos wrote:
| Two things:
|
| 1. (As another commenter mentioned) Most GNU projects are not
| standards that are expected to be adopted by a significant
| number of implementers, and used by a huge number of users.
| Most GNU projects are totally fine having a few maintainers.
|
| 2. I am a lot more comfortable with a GNU project being run by
| a single maintainer than a public specification being owned by
| a corporation, where changes to that specification are largely
| driven by that company's product choices and profit motive.
|
| And regardless, it seems a little weird to compare the GNU of
| the 80s and 90s to any public project today. In GNU's first 15
| years the internet was nascent (at best!), and the number of
| people who implemented, used, and cared about these sorts of
| things were orders of magnitude smaller than they are today.
| Needs have changed.
| jchw wrote:
| I think "truly open" is not specific enough. Not being
| developed "in the open" is one thing, not having "open
| governance" is another thing.
|
| That said, I guess the problem here is that for standards it
| helps if well, you collaborate with the people for which the
| standard is meant to be used by, which is presumably a little
| hard if there's a huge asymmetric relationship when it comes to
| Microsoft's concerns vs the rest of the world's concerns.
|
| This is one of those cases where having a standards committee
| or consortium is the way to go. Committees have their problems,
| but I think it's only reasonable. If you think about it,
| doesn't it seem inevitable that eventually, big organizations
| that make editors would want a consortium of some sort to
| collaborate on protocols like this? LSP is really just the
| beginning, since there are plenty of things that editors would
| probably like to integrate deeper with, such as build systems.
| pama wrote:
| How much easier is it to get the tree-sitter spec implemented for
| a new language compared to LSP? Are there synergies in getting
| both to work?
| kriiuuu wrote:
| Significantly easier because there is just a lot less surface
| area.
| IshKebab wrote:
| Tree Sitter doesn't do a tenth of what most LSP servers do, so
| it's much easier. But they aren't really related. Tree Sitter
| is a parser that you might _use_ in an LSP server (I have done;
| worked decently).
| ramon156 wrote:
| Apples to Oranges
| kayodelycaon wrote:
| > The LSP specification is big. Really big. Last time I checked
| it had 90 (!) methods and 407 (!!) types. Printing it to a PDF
| gives you 285 pages (!!!).
|
| Given what it does, that's pretty dang small. You don't get all
| those features across every programming language without some
| complexity.
|
| Compared to the 3,000+ pages specifications I've dealt with, this
| is easy.
|
| I have a very tiny violin and a cricket to play it for anyone
| complaining about a few hundred pages. :)
| saghm wrote:
| What sticks out to me is that there's less than one method per
| every four types. Given that, I assume that most of these types
| are just plain structs or type aliases; in other words, just
| names for things. I'm not sure what the author is trying to
| convey with that; would it be better if there were half as many
| types but they all had twice as many fields and methods and had
| to get used for multiple purposes?
|
| If the scope of the project is too large, that's certainly a
| valid complaint, but independent of somehow measuring the
| expected "size" of an API to cover a given scope, I don't
| really see how these raw numbers are particularly concerning.
| I'd be more concerned if the ratio of methods to types were
| reversed, but still a bit skeptical of any significance without
| more context.
| kayodelycaon wrote:
| For comparison, YAML is 77 pages.
| forrestthewoods wrote:
| LSP is pretty ok. Better than the before times I suppose.
| Although C++ has long had good IDE support so it hasn't affected
| me too much.
|
| I have a maybe wrong and bad opinion that LSP is actually at the
| wrong level. Right now every language needs to implement a from
| scratch implementation of their LSP server. These implementations
| are HUGE and take YEARS to develop. rust-analyzer is over 365,000
| lines of code. And every language has their own massive,
| independent implementation.
|
| When it comes to debugging all native language support common
| debug symbol formats. PDB for Windows and DWARF for Nixy things.
| Any compiled language that uses LLVM gets debug symbols and rich
| debugging "for free".
|
| I think there should be a common Intellisense Database file
| format for providing LSP or LSP-like capabilities. Ok sure there
| will still be per-language work to be done to implement the IDB
| format. But you'd get like 95% of the implementation for free for
| any LLVM language. And generating a common IDB format should be a
| lot simpler than implementing a kajillion LSP protocols.
|
| My dream world has a support file that contains: full debug
| symbols, full source code, and full intellisense data. It should
| be trivial to debug old binaries with full debugging, source, and
| intellisense. This world could exist and is within reach!
| nobodywasishere wrote:
| That sounds similar to LSIF
| https://microsoft.github.io/language-server-protocol/specifi...
| Zababa wrote:
| "any LLVM language" is a lot but also not that much. You're
| missing Python, JS, Go, Ruby, etc.
| PoignardAzur wrote:
| > _rust-analyzer is over 365,000 lines of code._
|
| That has nothing to do with LSP.
|
| Rust Analyzer is similar in scope to a second implementation of
| the Rust compiler.
| forrestthewoods wrote:
| > similar in scope to a second implementation of the Rust
| compiler.
|
| I know. That's really bad!
| csb6 wrote:
| The article touched on it, but it would be nice if there were a
| standard way to have extensions for LSP, e.g. a protocol that
| could be shared by language servers for formal specification
| languages that need proof obligation support. [0]
|
| [0] http://dx.doi.org/10.4204/EPTCS.338.3
| kelnos wrote:
| > _So I don't think it's really a good idea to do a big re-
| engineering of the protocol just to make it easier for
| implementers_
|
| I'm not so sure. Maybe it's not the case today, but if the
| protocol eventually becomes so large, so crufty, so under-
| specified that implementers struggle to provide their
| implementations, then users suffer.
| ogoffart wrote:
| I've implemented a LSP server (for Slint - https://slint.dev) and
| I agree with this article.
|
| The paradox is that it was meant to avoid to write language
| support for each editor. Yet, if you want to support vscode you
| must create a specific extension for it and can't just have a
| language client.
|
| The article mention the configuration problem, but I'd add the
| problem that Microsoft refuses to specify a way for the server to
| tell the client what are the config options so that the client
| can show some kind UI showing the possible configuration options
| with a description of what they do.
| https://github.com/microsoft/language-server-protocol/issues...
___________________________________________________________________
(page generated 2024-09-06 23:00 UTC)