4 ms·

Half of the changes are due to the language server implementing refactoring and other similar stuff. This shows clearly why the language server protocol is suc

Half of the changes are due to the language server implementing refactoring and other similar stuff. This shows clearly why the language server protocol is such a bad design decision and so broken — every language has to implement it itself, and there are no shared features or functionality across languages. Coming from IDEA, where the exact same refactoring functionality and features work no matter if using typescript, kotlin, Rust, C#, golang or dart, exactly identical in all ways, this has been a huge issue for myself. Languages Servers should just expose a clean standardized AST format, representing standardized nodes, and this should in turn allow the IDE to act upon this (which would immediately be represented in changed source).

tristanstcyr 6y ago
Language servers could still do this by reusing AST manipulation libraries behind the scenes.
eknkc 6y ago
I feel like this is wishful thinking. There is no way you can abstract away so many differences between languages for this to work effectively (or anywhere near as good as a tailor fitted refactoring engine to specific languages) IDEA does a lot of language specific stuff, it just unifies the UX. Which is what language servers aim anyway. BTW, I'm a long term user of powerline-go. Fantastic piece of software!
- kuschku 6y ago
  > IDEA does a lot of language specific stuff, it just unifies the UX. Which is what language servers aim anyway. Yeah, but with IDEA I have the exact same functionality for Rust, Typescript or Java, while the language servers will never agree on the exact same functions being called the same and doing exactly the same. It means relearning your editor every time you switch your language. I realize I’m probably in the minority as a person who writes basically every project in another language, whichever happens to work best for the project, while most others probably use only a few languages for most of their career, but it’s still annoying.
tgv 6y ago
That would limit the refactoring to a few common operations, and even those would be increasingly harder to implement for every new language added.
cactus2093 6y ago
All you're saying is that IDEA is currently more mature than language server support for most languages. That's obvious, and it doesn't say anything about whether the language server design & protocol itself is good or bad. I don't see anything inherently more generic or extensible about IDEA, they're just further along with more languages implemented. On top of that most LSP implementations are open source which lowers the cost of entry for developers and avoids lock-in with proprietary IDE's. And the well specified network protocol makes it much more flexible to different dev setups (e.g. run the LSP on more powerful cloud/remote hardware for large apps, use it with docker-based development setups, etc). So I would argue the exact opposite, the model of proprietary IDE's building walled gardens around so much useful developer tooling for otherwise open-source languages and ecosystems, is what is broken.
- kuschku 6y ago
  What I’m mostly saying is that with such a heterogeneous group of LSPs, they’ll never end up providing the same options — they’ll name them differently, they’ll work differently, etc. Every editor works the same now — but every language completely different. A user writing JS in vim can write it the same way in VSCode or Atom, but a user using Atom to write JS can’t write Rust in Atom the same way. I’d love to see a different LSP protocol, one where the LSP exposes much more information, and the editor implements the functionality on top of that, so every language works the same.
root_axis 6y ago
LSP has one immense advantage over IDEA: it's not a proprietary product coupled to one IDE.
- Scarbutt 6y ago
  Technically, that's also is a disadvantage though, Intellij doesn't have constraints because it only needs to cater its IDEs. But to your point, LSP have brought the IDE experience to others programming editors. Ex: Emacs now can do everything VSCode does for JS because of LSP.
Jasper_ 6y ago
Sounds like you should write a language server that uses a clean, standardized AST format for a number of languages under the hood. That sounds like a good way to trial the approach.

tristanstcyr 6y ago

Language servers could still do this by reusing AST manipulation libraries behind the scenes.

eknkc 6y ago

I feel like this is wishful thinking. There is no way you can abstract away so many differences between languages for this to work effectively (or anywhere near as good as a tailor fitted refactoring engine to specific languages) IDEA does a lot of language specific stuff, it just unifies the UX. Which is what language servers aim anyway. BTW, I'm a long term user of powerline-go. Fantastic piece of software!

kuschku 6y ago
> IDEA does a lot of language specific stuff, it just unifies the UX. Which is what language servers aim anyway. Yeah, but with IDEA I have the exact same functionality for Rust, Typescript or Java, while the language servers will never agree on the exact same functions being called the same and doing exactly the same. It means relearning your editor every time you switch your language. I realize I’m probably in the minority as a person who writes basically every project in another language, whichever happens to work best for the project, while most others probably use only a few languages for most of their career, but it’s still annoying.

tgv 6y ago

That would limit the refactoring to a few common operations, and even those would be increasingly harder to implement for every new language added.

cactus2093 6y ago

All you're saying is that IDEA is currently more mature than language server support for most languages. That's obvious, and it doesn't say anything about whether the language server design & protocol itself is good or bad. I don't see anything inherently more generic or extensible about IDEA, they're just further along with more languages implemented. On top of that most LSP implementations are open source which lowers the cost of entry for developers and avoids lock-in with proprietary IDE's. And the well specified network protocol makes it much more flexible to different dev setups (e.g. run the LSP on more powerful cloud/remote hardware for large apps, use it with docker-based development setups, etc). So I would argue the exact opposite, the model of proprietary IDE's building walled gardens around so much useful developer tooling for otherwise open-source languages and ecosystems, is what is broken.

kuschku 6y ago
What I’m mostly saying is that with such a heterogeneous group of LSPs, they’ll never end up providing the same options — they’ll name them differently, they’ll work differently, etc. Every editor works the same now — but every language completely different. A user writing JS in vim can write it the same way in VSCode or Atom, but a user using Atom to write JS can’t write Rust in Atom the same way. I’d love to see a different LSP protocol, one where the LSP exposes much more information, and the editor implements the functionality on top of that, so every language works the same.

root_axis 6y ago

LSP has one immense advantage over IDEA: it's not a proprietary product coupled to one IDE.

Scarbutt 6y ago
Technically, that's also is a disadvantage though, Intellij doesn't have constraints because it only needs to cater its IDEs. But to your point, LSP have brought the IDE experience to others programming editors. Ex: Emacs now can do everything VSCode does for JS because of LSP.

Jasper_ 6y ago

Sounds like you should write a language server that uses a clean, standardized AST format for a number of languages under the hood. That sounds like a good way to trial the approach.