5 ms·

The benefit of the LSP is being able to integrate with any text editor. Focusing on an IDEA plugin would leave behind the many developers who prefer VSCode, Vim

The benefit of the LSP is being able to integrate with any text editor. Focusing on an IDEA plugin would leave behind the many developers who prefer VSCode, Vim, Emacs, etc.

kuschku 6y ago
The LSP means every single language server has to reinvent the wheel again and again. It’d have been much more useful to build bindings for IDEA plugins so they could be integrated into arbitrary editors, especially as the IDEA plugins for most languages even after several years of LSP development are still superior. All in all it’s like the whole JVM vs. WASM, Java vs Electron story again, with someone deciding to reinvent the wheel but worse. There’s even bindings like https://github.com/Ruin0x11/intellij-lsp-server https://github.com/Ruin0x11/intellij-lsp-server or https://plugins.jetbrains.com/plugin/10209-lsp-support https://plugins.jetbrains.com/plugin/10209-lsp-support to glue it all back together. It’d have been much simpler to reuse an existing ecosystem from the start.
- brundolf 6y ago
  Presumably IDEA plugins have to be written in JVM languages, and use specific language-level bindings, and I would bet they're not very well decoupled from IDEA itself (which would make it really hard to write adapters to other editors). Language servers are just that: servers, exposing a very unopinionated API. They run in a separate process, can be written in any language, and can even be hosted from any machine. That makes for a much more open and flexible standard.
  - kuschku 6y ago
    Sure, but imagine if the LSP designers had, as first project, just written a binding for IDEA. Then VSCode could've immediately had all the advantages of IDEA, and we'd be able to use both interchangeably.
    - brundolf 6y ago
      I maintain that that would've been much harder to implement, for VSCode and for all other editors that followed. Among other issues, it would require a separate JVM process and some way for other languages to bind directly to JVM interfaces in that process, since most non-Java editors are not written in JVM languages. If what you're suggesting is an LSP that wraps any given IDEA plugin and maps it to the LSP protocol, well, that can still be done (assuming it could ever be done) and would've still required the LSP protocol to be invented first. On top of all that: you're welcome to re-use any code out there (in any language!) when writing an LSP. Nothing stops you from leveraging the bulk of an IDEA plugin, or whatever generic compiler utilities go into IDEA, when making your own LSP. I wouldn't say any work is wasted at all.
- oaiey 6y ago
  Same is true for compilers. and actually, modern compilers already include the LSP business logic. Therefore, it is not a waste. Especially since languages exist outside of a single idea system like IDEA
  - kuschku 6y ago
    > Same is true for compilers. Which are mostly collections of dozens of languages and dozens of backends reusing the same functionality in compiler collections like the GCC or LLVM. Instead, with LSP, every single one reimplements everything from scratch. And the features available to you differ heavily from one language to another.
    - brundolf 6y ago
      > every single one reimplements everything from scratch Still not sure where you're getting this idea that everything has to be done over from scratch. Code sharing is code sharing; the only new thing that fundamentally has to be written is the mapping to a particular public interface, but that had to be done anyway because no previous interface was generic enough to be used by all possible editors. As an example: the original RLS mostly just uses Rust's existing compiler internals. It doesn't perform super well, because rustc is optimized for full-build usecases and not interactive/partial usecases. But it didn't have to be written in a clean-room environment just because it's exposing a new API to the outside world.
      - kuschku 6y ago
        Rustc has code to refactor-rename variables across multiple files? Code to extract the implementation of a function out into a separate file? Code to turn duplicated code automatically into a macro? The significant task in a language server isn't the "parse and show types" part but the "provide resharper-like refactoring functionality". And every single language server has to reimplement all these from scratch. And every single language server ends up with slightly different refactoring functionality, no standardisation or anything. Compare that to IDEA, where changing the type of a function at one point, and propagating that change to all calling functions across the whole code base is a single key stroke — and always the same, no matter which language you use. That's what I'm complaining about. LSP is an improvement for editors, but significantly worse than the alternative for actual IDEs.

The benefit of the LSP is being able to integrate with any text editor. Focusing on an IDEA plugin would leave behind the many developers who prefer VSCode, Vim, Emacs, etc.

kuschku 6y ago

The LSP means every single language server has to reinvent the wheel again and again. It’d have been much more useful to build bindings for IDEA plugins so they could be integrated into arbitrary editors, especially as the IDEA plugins for most languages even after several years of LSP development are still superior. All in all it’s like the whole JVM vs. WASM, Java vs Electron story again, with someone deciding to reinvent the wheel but worse. There’s even bindings like https://github.com/Ruin0x11/intellij-lsp-server https://github.com/Ruin0x11/intellij-lsp-server or https://plugins.jetbrains.com/plugin/10209-lsp-support https://plugins.jetbrains.com/plugin/10209-lsp-support to glue it all back together. It’d have been much simpler to reuse an existing ecosystem from the start.

brundolf 6y ago
Presumably IDEA plugins have to be written in JVM languages, and use specific language-level bindings, and I would bet they're not very well decoupled from IDEA itself (which would make it really hard to write adapters to other editors). Language servers are just that: servers, exposing a very unopinionated API. They run in a separate process, can be written in any language, and can even be hosted from any machine. That makes for a much more open and flexible standard.
- kuschku 6y ago
  Sure, but imagine if the LSP designers had, as first project, just written a binding for IDEA. Then VSCode could've immediately had all the advantages of IDEA, and we'd be able to use both interchangeably.
  - brundolf 6y ago
    I maintain that that would've been much harder to implement, for VSCode and for all other editors that followed. Among other issues, it would require a separate JVM process and some way for other languages to bind directly to JVM interfaces in that process, since most non-Java editors are not written in JVM languages. If what you're suggesting is an LSP that wraps any given IDEA plugin and maps it to the LSP protocol, well, that can still be done (assuming it could ever be done) and would've still required the LSP protocol to be invented first. On top of all that: you're welcome to re-use any code out there (in any language!) when writing an LSP. Nothing stops you from leveraging the bulk of an IDEA plugin, or whatever generic compiler utilities go into IDEA, when making your own LSP. I wouldn't say any work is wasted at all.
oaiey 6y ago
Same is true for compilers. and actually, modern compilers already include the LSP business logic. Therefore, it is not a waste. Especially since languages exist outside of a single idea system like IDEA
- kuschku 6y ago
  > Same is true for compilers. Which are mostly collections of dozens of languages and dozens of backends reusing the same functionality in compiler collections like the GCC or LLVM. Instead, with LSP, every single one reimplements everything from scratch. And the features available to you differ heavily from one language to another.
  - brundolf 6y ago
    > every single one reimplements everything from scratch Still not sure where you're getting this idea that everything has to be done over from scratch. Code sharing is code sharing; the only new thing that fundamentally has to be written is the mapping to a particular public interface, but that had to be done anyway because no previous interface was generic enough to be used by all possible editors. As an example: the original RLS mostly just uses Rust's existing compiler internals. It doesn't perform super well, because rustc is optimized for full-build usecases and not interactive/partial usecases. But it didn't have to be written in a clean-room environment just because it's exposing a new API to the outside world.
    - kuschku 6y ago
      Rustc has code to refactor-rename variables across multiple files? Code to extract the implementation of a function out into a separate file? Code to turn duplicated code automatically into a macro? The significant task in a language server isn't the "parse and show types" part but the "provide resharper-like refactoring functionality". And every single language server has to reimplement all these from scratch. And every single language server ends up with slightly different refactoring functionality, no standardisation or anything. Compare that to IDEA, where changing the type of a function at one point, and propagating that change to all calling functions across the whole code base is a single key stroke — and always the same, no matter which language you use. That's what I'm complaining about. LSP is an improvement for editors, but significantly worse than the alternative for actual IDEs.