3 ms·

Is rust-analyzer's relative modernity a symptom of intrinsic limitations behind Language Server, or tactical limitations of RLS? I was very hopeful about the b

by 013a 6y ago

Is rust-analyzer's relative modernity a symptom of intrinsic limitations behind Language Server, or tactical limitations of RLS? I was very hopeful about the bright future of language server, and its ability to solve that N^2'd problem between editors, addons, and languages. But, if it can't provide truly great experiences outside of Typescript (which has been my unfortunate experience), it does not bode well for the project.

Argorak 6y ago
The latter. rust-analyzer implements the language server protocol like RLS. RLS was implemented using the compiler as a library, which meant it inherited the compilation model of the compiler, which isn't really well-suited for IDEs. That was done in full knowledge of that drawback. The advantage for RLS is that it has perfect parity with the language. This may be fixed by using rust-analyzers libraries within the compiler. RFC here: https://github.com/rust-lang/rfcs/pull/2912 https://github.com/rust-lang/rfcs/pull/2912
- 013a 6y ago
  Excellent to hear. This was not obvious from the blog post, and I should have done more digging before jumping to conclusions.
  - Argorak 6y ago
    Not you fault, thanks for asking :).
  - raziel2p 6y ago
    From the article: > We build the rust-analyzer binary, an implementation of the language server protocol, which can provide a basic IDE experience for Rust today.
matklad 6y ago
I must say I don't fully understand your original question, so I can't answer it directly. However, I can share my (very hand-wavy) thoughts on the general LSP ecosystem, and it looks like that might actually answer your question. I personally don't believe that NxM is a real problem. If you have an editor, which has bespoke APIs for providing completion, and a language server, which speaks bespoke protocol, binding the two together is not hard. A single person can do that and if, say, at least 1000 people use editor X with language Y, it doesn't seem like a waste of effort to me. The problem is that writing a language server that works is hard. "Rewrite your entire compiler from scratch" kind of hard. Before LSP, only JetBrains delivered these kinds of compilers consistently. Notable non-JetBrains tools from before LSP era are Roslyn and Dart Analyzer. The Dart Analyzer project is particularly interesting -- it's the same "separate server process speaking JSON" kind of architecture. The details of protocol are different (as it predates LSP) and it doesn't try to be language agnostic. Dart support in IntelliJ is powered primarily by this server. In my mind, the main value of LSP is social: it pushes language designers and compiler writers to think about editing and refactoring incomplete code, which is a very different problem from compiling mostly correct code.

by 013a 6y ago

Argorak 6y ago

The latter. rust-analyzer implements the language server protocol like RLS. RLS was implemented using the compiler as a library, which meant it inherited the compilation model of the compiler, which isn't really well-suited for IDEs. That was done in full knowledge of that drawback. The advantage for RLS is that it has perfect parity with the language. This may be fixed by using rust-analyzers libraries within the compiler. RFC here: https://github.com/rust-lang/rfcs/pull/2912 https://github.com/rust-lang/rfcs/pull/2912

013a 6y ago
Excellent to hear. This was not obvious from the blog post, and I should have done more digging before jumping to conclusions.
- Argorak 6y ago
  Not you fault, thanks for asking :).
- raziel2p 6y ago
  From the article: > We build the rust-analyzer binary, an implementation of the language server protocol, which can provide a basic IDE experience for Rust today.

matklad 6y ago

I must say I don't fully understand your original question, so I can't answer it directly. However, I can share my (very hand-wavy) thoughts on the general LSP ecosystem, and it looks like that might actually answer your question. I personally don't believe that NxM is a real problem. If you have an editor, which has bespoke APIs for providing completion, and a language server, which speaks bespoke protocol, binding the two together is not hard. A single person can do that and if, say, at least 1000 people use editor X with language Y, it doesn't seem like a waste of effort to me. The problem is that writing a language server that works is hard. "Rewrite your entire compiler from scratch" kind of hard. Before LSP, only JetBrains delivered these kinds of compilers consistently. Notable non-JetBrains tools from before LSP era are Roslyn and Dart Analyzer. The Dart Analyzer project is particularly interesting -- it's the same "separate server process speaking JSON" kind of architecture. The details of protocol are different (as it predates LSP) and it doesn't try to be language agnostic. Dart support in IntelliJ is powered primarily by this server. In my mind, the main value of LSP is social: it pushes language designers and compiler writers to think about editing and refactoring incomplete code, which is a very different problem from compiling mostly correct code.