6 ms·

I tried a few language plugins for VSCode that were all based on LSP, and they were all broken. So for me, the question is wrong. It's not "Why is LSP so great

by hsn915 5y ago

I tried a few language plugins for VSCode that were all based on LSP, and they were all broken. So for me, the question is wrong. It's not "Why is LSP so great?". The question should be "Why are people so hyped about tech that's based on questionable assumptions and that hasn't proved itself?" The reason VSCode invented LSP is that different programming languages don't have a reliable way to intercommunicate (other than as separate processes communicating over a socket).

adwn 5y ago
> The reason VSCode invented LSP is that different programming languages don't have a reliable way to intercommunicate (other than as separate processes communicating over a socket). The processes-communicating-via-IPC architecture is way underrated for plugins. It's much easier to separate the plugin from the host, and to cleanly stop or restart the plugin. For example, sometimes (rarely) rust-analyzer hits a bug and starts consuming 100% CPU. When that happens, I just kill that process and VS Code transparently restarts rust-analyzer; I don't have to restart the IDE, and all other plugins are unaffected as well. That would be practically impossible if rust-analyzer were a library instead of an independent process.
- zozbot234 5y ago
  That's because separate processes are not "plugins" at all, but part of an outside toolset that may or may not be supported by a thin "plugin"-like IDE component. The patterns involved are completely different; the separate-processes pattern was popularized by *nix, whereas plugins were always more common in Windows and Mac.
  - adwn 5y ago
    The concept of a "plugin" isn't restricted to dynamically linking shared libraries, but rather defined by the concept of having an independent host application, which can load additional functionality at runtime. It doesn't matter whether this is achieved through shared libraries, interpreted code, or separate processes.
- mike_hearn 5y ago
  Hmm. I have the opposite impression - separate processes using IPC seems way overrated to me, especially for language servers. When you compare the IntelliJ architecture to VSC it's hard to escape the feeling that LSP exists only because JavaScript isn't type or thread safe. In such a language you have no choice but to create a 'backend' of some sort that exchanges messages with the frontend. Yet that's not a great way to implement an IDE. The task is just fundamentally well suited to fast, memory safe, type safe, thread safe languages and very poorly suited to languages like JS and Rust. Why is that? 1. An in-process type safe API can be evolved and iterated rapidly. There's no need to write informal English specs for everything because the API itself provides so much guidance. Actually, IntelliJ is rather notorious for its absence of JavaDocs though this reflects cultural decisions inside JetBrains itself more than anything intrinsic (they take "code should be self documenting" perhaps a bit too seriously). In contrast, the LSP spec is enormous and the document itself doesn't provide much assistance implementing it (the article discusses this somewhat). 2. A protocol spec doesn't give you any re-usable code. If you write an IntelliJ plugin there's tons of re-usable helper logic and you can easily customize other plugins. The whole thing is designed for on-the-fly presentation compilers. With LSP you may or may not have anything to base your work on. 3. An IDE is fundamentally a highly parallel mutable database, in which the data can be in arbitrarily invalid forms at any point and the user is allowed to change anything whilst many different analyses are running in parallel. Shared data structures are everything in this problem, yet the LSP model effectively forbids all shared state between backend and frontend. This feels like a constraint inherited from browsers - it arguable doesn't make things easier, it just replaces relatively simple and statically/dynamically analyzable locking protocols with complicated sync and rec protocols. Both sides have to maintain their own copies of each other's data structures instead of re-using a single source of truth. This can get really messy, really fast. You're also constantly paying the costs and overheads of multi-process like context switching (especially expensive on Windows), IPC copies, process overhead, serialization etc. 4. A presentation compiler doesn't seem to benefit much from being written in Rust or C++. Developer workstations are fast and have plenty of RAM, so GCd/JITd languages don't seem like a particular problem here. Developer productivity on the other hand is at a premium. People want features. One reason JetBrains can add new languages and features so fast is that they're writing in relatively forgiving languages like Java and Kotlin, where you don't have to think too hard about ownership or memory management. Some thought is still needed - see the disposable model inside their IDEs - but you can more or less just go for it with a high rate of feature throughput. You raise the question of how to kill hung operations. In practice that doesn't seem to be a common problem. I've been using IntelliJ with various languages for years and there have been many bugs, but I can't remember any time that a plugin hard-hung whilst analyzing. There are cases where plugin bugs happen but exceptions and GC mean the IDE can simply catch the errors and disable it. These days it can do that temporarily and simply reload the plugin on the fly. Other times e.g. if a pure static analysis crashes it just logs the error and uploads it for analysis. That particular analysis might not appear as a consequence but there are so many different optional quality-of-life analyses being done you often hardly notice.
- hsn915 5y ago
  What you just described with great enthusiasm as a feature is to me a terrible bug. It means that as a user of the system you must understand the inner workings of the system. Imagine someone says this about a car. "If you are driving on the highway and some component dies midway, you just open the cover and press a button on the broken component and it restarts itself! Isn't that much better than waiting two weeks for some repairman to repair it?" I don't want a car that has components that just randomly die mid flight. That's not a feature. It's a deal breaker. In more general terms, a system where failures are hard is easier to make robust because the errors are visible to developers. In a dynamic system where failures are "not my problem", it's very easy for the system to develop into a wobbly unstable mess, because no one owns the system. It's just a bunch of plugins that may or may not behave erratically. That's not a good way to build a stable relaible IDE.
  - adwn 5y ago
    Isolating failures to small, restartable components, instead of letting them spread to the entire system, is a bug in your eyes?! Do you think rust-analyzer wouldn't ever crash if it were loaded and tightly integrated into the address space of VS Code? Completely bug-free software is a desirable, but utopian goal. What do you think why processes with separate address spaces were invented? Would you rather go back to the Windows 3.1x days where a bug in a single program could bring down your entire system? Do you believe those programs were "easier to make robust because the errors [were] visible to developers"? > "If you are driving on the highway and some component dies midway, you just open the cover and press a button on the broken component and it restarts itself! Isn't that much better than waiting two weeks for some repairman to repair it?" Yes, that would be much, much better than waiting for two weeks while being stranded in the middle of nowhere.
    - hsn915 5y ago
      > Isolating failures to small, restartable components, instead of letting them spread to the entire system, is a bug in your eyes?! Do you think rust-analyzer wouldn't ever crash if it were loaded and tightly integrated into the address space of VS Code? How far would you extrapolate this? Where would you draw the line? Would you say VS Code would be more resiliant and reliable if it had more isoldated processes for different parts of the editor? - Process to blink the cursor - Process to render the text - Process to run syntax highlighting on the text - Process to show the buttons on the left most side bar - Process to draw the file/directory tree I think it would be obvious that this would be insane. Yet, why should it be? Wouldn't it be better - according to this way of thinking - because it means the editor will not crash if the cursor blinking code crashed! or if the file tree viewer crashed!
carlmr 5y ago
So I would say rust-analyzer works quite well, while Rust RLS is terrible. However that seems to be a non-LSP issue. The F# ionide plugin also works really well, it's also LSP based? Most issues with the VSCode plugins I have is that they don't report errors to the user properly. It's really hard to find out _why_ something is failing. So when everything is configured correctly, the LSP works great. When you have a misconfiguration you need to play detective. Plenty of plugins hang forever, fail silently, or they give you very generic error messages. But this seems to be a VSCode issue.
- hsn915 5y ago
  The only "LSP" plugins that work well with VSCode in my experience are those developed by Microsoft (likely by the same team that developed VSCode). But even then, not all of them are great. For example, the Python plugin is of questionable quality, but that is probably because Python does not amend itself well to intellisense, even when you add type hints to the picture. > Most issues with the VSCode plugins I have is that they don't report errors to the user properly. It's really hard to find out _why_ something is failing. So when everything is configured correctly, the LSP works great. When you have a misconfiguration you need to play detective. Good observation. This is not just a "feature" of LSPs. It's a feature of all distributed systems developed with the unix mindset. For example, Docker suffers the same problem. Someone gives you a docker image, it works great! For a while. But when something breaks, it really breaks, and it doesn't tell you why. It prints some superfluous error message; one that does not help you understand what's going on.
  - carlmr 5y ago
    >It's a feature of all distributed systems developed with the unix mindset. That is also a good observation. It's hard to create a good UX with a system where you don't somehow handle all of the failures of the subsystem in a central manner. My problem here with VSCode is that it often doesn't even expose the failure of the subsystem, essentially not even giving you the information you need to find out the issue. If my corporate proxy fails, the extension store will say "XHR failed", and before it used to just hang forever. But as a user, what is XHR? Why does this hang forever now? There could be many reasons. At least tell me that you had a failure while downloading something.

by hsn915 5y ago

adwn 5y ago

> The reason VSCode invented LSP is that different programming languages don't have a reliable way to intercommunicate (other than as separate processes communicating over a socket). The processes-communicating-via-IPC architecture is way underrated for plugins. It's much easier to separate the plugin from the host, and to cleanly stop or restart the plugin. For example, sometimes (rarely) rust-analyzer hits a bug and starts consuming 100% CPU. When that happens, I just kill that process and VS Code transparently restarts rust-analyzer; I don't have to restart the IDE, and all other plugins are unaffected as well. That would be practically impossible if rust-analyzer were a library instead of an independent process.

zozbot234 5y ago
That's because separate processes are not "plugins" at all, but part of an outside toolset that may or may not be supported by a thin "plugin"-like IDE component. The patterns involved are completely different; the separate-processes pattern was popularized by *nix, whereas plugins were always more common in Windows and Mac.
- adwn 5y ago
  The concept of a "plugin" isn't restricted to dynamically linking shared libraries, but rather defined by the concept of having an independent host application, which can load additional functionality at runtime. It doesn't matter whether this is achieved through shared libraries, interpreted code, or separate processes.
mike_hearn 5y ago
Hmm. I have the opposite impression - separate processes using IPC seems way overrated to me, especially for language servers. When you compare the IntelliJ architecture to VSC it's hard to escape the feeling that LSP exists only because JavaScript isn't type or thread safe. In such a language you have no choice but to create a 'backend' of some sort that exchanges messages with the frontend. Yet that's not a great way to implement an IDE. The task is just fundamentally well suited to fast, memory safe, type safe, thread safe languages and very poorly suited to languages like JS and Rust. Why is that? 1. An in-process type safe API can be evolved and iterated rapidly. There's no need to write informal English specs for everything because the API itself provides so much guidance. Actually, IntelliJ is rather notorious for its absence of JavaDocs though this reflects cultural decisions inside JetBrains itself more than anything intrinsic (they take "code should be self documenting" perhaps a bit too seriously). In contrast, the LSP spec is enormous and the document itself doesn't provide much assistance implementing it (the article discusses this somewhat). 2. A protocol spec doesn't give you any re-usable code. If you write an IntelliJ plugin there's tons of re-usable helper logic and you can easily customize other plugins. The whole thing is designed for on-the-fly presentation compilers. With LSP you may or may not have anything to base your work on. 3. An IDE is fundamentally a highly parallel mutable database, in which the data can be in arbitrarily invalid forms at any point and the user is allowed to change anything whilst many different analyses are running in parallel. Shared data structures are everything in this problem, yet the LSP model effectively forbids all shared state between backend and frontend. This feels like a constraint inherited from browsers - it arguable doesn't make things easier, it just replaces relatively simple and statically/dynamically analyzable locking protocols with complicated sync and rec protocols. Both sides have to maintain their own copies of each other's data structures instead of re-using a single source of truth. This can get really messy, really fast. You're also constantly paying the costs and overheads of multi-process like context switching (especially expensive on Windows), IPC copies, process overhead, serialization etc. 4. A presentation compiler doesn't seem to benefit much from being written in Rust or C++. Developer workstations are fast and have plenty of RAM, so GCd/JITd languages don't seem like a particular problem here. Developer productivity on the other hand is at a premium. People want features. One reason JetBrains can add new languages and features so fast is that they're writing in relatively forgiving languages like Java and Kotlin, where you don't have to think too hard about ownership or memory management. Some thought is still needed - see the disposable model inside their IDEs - but you can more or less just go for it with a high rate of feature throughput. You raise the question of how to kill hung operations. In practice that doesn't seem to be a common problem. I've been using IntelliJ with various languages for years and there have been many bugs, but I can't remember any time that a plugin hard-hung whilst analyzing. There are cases where plugin bugs happen but exceptions and GC mean the IDE can simply catch the errors and disable it. These days it can do that temporarily and simply reload the plugin on the fly. Other times e.g. if a pure static analysis crashes it just logs the error and uploads it for analysis. That particular analysis might not appear as a consequence but there are so many different optional quality-of-life analyses being done you often hardly notice.
hsn915 5y ago
What you just described with great enthusiasm as a feature is to me a terrible bug. It means that as a user of the system you must understand the inner workings of the system. Imagine someone says this about a car. "If you are driving on the highway and some component dies midway, you just open the cover and press a button on the broken component and it restarts itself! Isn't that much better than waiting two weeks for some repairman to repair it?" I don't want a car that has components that just randomly die mid flight. That's not a feature. It's a deal breaker. In more general terms, a system where failures are hard is easier to make robust because the errors are visible to developers. In a dynamic system where failures are "not my problem", it's very easy for the system to develop into a wobbly unstable mess, because no one owns the system. It's just a bunch of plugins that may or may not behave erratically. That's not a good way to build a stable relaible IDE.
- adwn 5y ago
  Isolating failures to small, restartable components, instead of letting them spread to the entire system, is a bug in your eyes?! Do you think rust-analyzer wouldn't ever crash if it were loaded and tightly integrated into the address space of VS Code? Completely bug-free software is a desirable, but utopian goal. What do you think why processes with separate address spaces were invented? Would you rather go back to the Windows 3.1x days where a bug in a single program could bring down your entire system? Do you believe those programs were "easier to make robust because the errors [were] visible to developers"? > "If you are driving on the highway and some component dies midway, you just open the cover and press a button on the broken component and it restarts itself! Isn't that much better than waiting two weeks for some repairman to repair it?" Yes, that would be much, much better than waiting for two weeks while being stranded in the middle of nowhere.
  - hsn915 5y ago
    > Isolating failures to small, restartable components, instead of letting them spread to the entire system, is a bug in your eyes?! Do you think rust-analyzer wouldn't ever crash if it were loaded and tightly integrated into the address space of VS Code? How far would you extrapolate this? Where would you draw the line? Would you say VS Code would be more resiliant and reliable if it had more isoldated processes for different parts of the editor? - Process to blink the cursor - Process to render the text - Process to run syntax highlighting on the text - Process to show the buttons on the left most side bar - Process to draw the file/directory tree I think it would be obvious that this would be insane. Yet, why should it be? Wouldn't it be better - according to this way of thinking - because it means the editor will not crash if the cursor blinking code crashed! or if the file tree viewer crashed!

carlmr 5y ago

So I would say rust-analyzer works quite well, while Rust RLS is terrible. However that seems to be a non-LSP issue. The F# ionide plugin also works really well, it's also LSP based? Most issues with the VSCode plugins I have is that they don't report errors to the user properly. It's really hard to find out _why_ something is failing. So when everything is configured correctly, the LSP works great. When you have a misconfiguration you need to play detective. Plenty of plugins hang forever, fail silently, or they give you very generic error messages. But this seems to be a VSCode issue.

hsn915 5y ago
The only "LSP" plugins that work well with VSCode in my experience are those developed by Microsoft (likely by the same team that developed VSCode). But even then, not all of them are great. For example, the Python plugin is of questionable quality, but that is probably because Python does not amend itself well to intellisense, even when you add type hints to the picture. > Most issues with the VSCode plugins I have is that they don't report errors to the user properly. It's really hard to find out _why_ something is failing. So when everything is configured correctly, the LSP works great. When you have a misconfiguration you need to play detective. Good observation. This is not just a "feature" of LSPs. It's a feature of all distributed systems developed with the unix mindset. For example, Docker suffers the same problem. Someone gives you a docker image, it works great! For a while. But when something breaks, it really breaks, and it doesn't tell you why. It prints some superfluous error message; one that does not help you understand what's going on.
- carlmr 5y ago
  >It's a feature of all distributed systems developed with the unix mindset. That is also a good observation. It's hard to create a good UX with a system where you don't somehow handle all of the failures of the subsystem in a central manner. My problem here with VSCode is that it often doesn't even expose the failure of the subsystem, essentially not even giving you the information you need to find out the issue. If my corporate proxy fails, the extension store will say "XHR failed", and before it used to just hang forever. But as a user, what is XHR? Why does this hang forever now? There could be many reasons. At least tell me that you had a failure while downloading something.