5 ms·

One of the things that baffles me is the rust-Lang support. Rust-lang has an official dual-licensed MIT/Apache language server protocol implementation (RLS) un

One of the things that baffles me is the rust-Lang support. Rust-lang has an official dual-licensed MIT/Apache language server protocol implementation (RLS) under active development. In my view it’s currently a better experience than the custom IntelliJ one. Instead of collaborating though I see IntelliJ continuing on the path of their custom implementation. Every week RLS gives an update on their progress and so does IntelliJ on their rust plugin, but it just seems like so much duplicates effort.

nyanpasu64 6y ago
Do you mean rust-analyzer's good experience and progress updates? RLS is in maintenance mode and deprecated in favor of rust-analyzer.
- skohan 6y ago
  So will rust-analyzer also replace rustc eventually as the main rust compiler? Seems like a lot of overhead to keep two compiler versions at parity.
  - CryZe 6y ago
    rust-analyzer is not a compiler. They plan on sharing a lot of code though.
  - dralley 6y ago
    No, the goals of an IDE-oriented compiler are largely different from the goals of a bulk code compiler. They can / will share substantial amounts of code though. Quoting a developer: >>>>>>>>>>>>>>>>>>> Aleksey Kladov: The limitations here are not specific to the Rust language, but a general for command line vs IDE compiler. The main thing is that the command line (or batch) compiler is primarily optimized for throughput (compiling N thousands lines of code per second), while an IDE compiler is optimized for latency (showing correct completion variants in M milliseconds after user typed new fragment of code). As usual with throughput vs latency, these two goals require pretty different optimizations (and even high-level architectures). In general, it's hard to retrofit low latency requirement on a compiler which was developed solely with big throughput in mind. Another thing is difference in handling invalid code. A traditional compiler front-end is usually organized as a progression of phases, where each phase takes an unstructured input, checks the input for validity, and, if it is indeed valid, adds more structure on top. Specifically, an error in an early phase (like parsing) usually means that the latter phase (like type checking) is not run for this bit of code at all. In other words, "correct code" is a happy case, and everything else can be treated as an error condition. In contrast, in IDE code is always broken, because the user constantly modifies it. As soon as the code is valid, the job of IDE ends and the job of the batch compiler begins. So, an IDE-oriented compiler should accommodate an incomplete and broken code, and provide IDE features, like completion, for such code.
pirocks 6y ago
A few years ago I contributed to an Intellij plugin with significantly less resources than the rust one. What became clear there was that external tools are glitchy, laggy, frequently crash, and don't quite match Intellij's model of things, native Intellij support will likely always be better.
sgeisler 6y ago
> Instead of collaborating though I see IntelliJ continuing on the path of their custom implementation. I haven't checked in a while, but RLS was sub-par for a long time (feature- and latencywise). Tight integration has its benefits if you can afford it (and apparently they can). So I guess as soon as they can get the same properties from RLS as from their own implementation they'd switch. But if it meant having to rewrite a lot of stuff that suddenly also becomes available to competitors that seems like a dumb move.
- iudqnolq 6y ago
  Their code is open source (if tightly linked to their codebase, of course) https://github.com/intellij-rust/intellij-rust https://github.com/intellij-rust/intellij-rust
matsemann 6y ago
I can think of multiple reasons they may prefer doing it themselves: Differentiation, if they just reuse the same thing everyone else does, they will have no moat or extra features. Or maybe because the language server protocol cannot handle everything IDEA normally provides, so they will have to run some kind of parser etc. on their end anyway. Or that interfacing with an external tool can be buggy or have weird boundaries making certain features harder to implement.
deleted 6y ago
[deleted]
specialp 6y ago
Besides Typescript, I haven't seen any language server do better in syntax completion and introspection better than the JetBrains equivalent. They probably don't want to work on it because 1. If they write their own they can make it work to exactly what they need, and 2. They would probably not leverage as much working on the OSS version as they'd lose by open sourcing and doing the bulk of the work on what makes them money. That might sound cold but it is not unreasonable.
- iudqnolq 6y ago
  It's MIT licensed https://github.com/intellij-rust/intellij-rust https://github.com/intellij-rust/intellij-rust
tsimionescu 6y ago
JetBrains have always developed their own language analyzers from what I've seen. I would bet they have a clear API between a language analyzer and their suite of refactoring and code navigation tools, and it would probably end up being similar to work to support that API through an open source variant VS building their own. Not to mention, JetBrains typically are at the forefront of IDE support for a language, they start working on it before there are any open source tools around to base work off of. Even with mature languages like C#, the JetBrains C# language backend predates Rosslyn by a good decade I think.
surajrmal 6y ago
There is nothing inherently wrong with solving a problem multiple ways. While it's usually good for smaller players in a space to work together, I'm always happy to see others that trod their own path. They can make different choices/tradeoffs, and learn from each other. This usually leads to better outcomes for both of their user bases.
dagmx 6y ago
I use both VSC and CLion, and CLion is a much better experience for Rust IMHO. I know the IntrlliJ only plugin is kind of lacking versus the CLion feature with regards to debugging, but overall I find CLions support to be miles ahead of rust analyzer for stability, speed and ease of use.

nyanpasu64 6y ago

Do you mean rust-analyzer's good experience and progress updates? RLS is in maintenance mode and deprecated in favor of rust-analyzer.

skohan 6y ago
So will rust-analyzer also replace rustc eventually as the main rust compiler? Seems like a lot of overhead to keep two compiler versions at parity.
- CryZe 6y ago
  rust-analyzer is not a compiler. They plan on sharing a lot of code though.
- dralley 6y ago
  No, the goals of an IDE-oriented compiler are largely different from the goals of a bulk code compiler. They can / will share substantial amounts of code though. Quoting a developer: >>>>>>>>>>>>>>>>>>> Aleksey Kladov: The limitations here are not specific to the Rust language, but a general for command line vs IDE compiler. The main thing is that the command line (or batch) compiler is primarily optimized for throughput (compiling N thousands lines of code per second), while an IDE compiler is optimized for latency (showing correct completion variants in M milliseconds after user typed new fragment of code). As usual with throughput vs latency, these two goals require pretty different optimizations (and even high-level architectures). In general, it's hard to retrofit low latency requirement on a compiler which was developed solely with big throughput in mind. Another thing is difference in handling invalid code. A traditional compiler front-end is usually organized as a progression of phases, where each phase takes an unstructured input, checks the input for validity, and, if it is indeed valid, adds more structure on top. Specifically, an error in an early phase (like parsing) usually means that the latter phase (like type checking) is not run for this bit of code at all. In other words, "correct code" is a happy case, and everything else can be treated as an error condition. In contrast, in IDE code is always broken, because the user constantly modifies it. As soon as the code is valid, the job of IDE ends and the job of the batch compiler begins. So, an IDE-oriented compiler should accommodate an incomplete and broken code, and provide IDE features, like completion, for such code.

pirocks 6y ago

A few years ago I contributed to an Intellij plugin with significantly less resources than the rust one. What became clear there was that external tools are glitchy, laggy, frequently crash, and don't quite match Intellij's model of things, native Intellij support will likely always be better.

sgeisler 6y ago

> Instead of collaborating though I see IntelliJ continuing on the path of their custom implementation. I haven't checked in a while, but RLS was sub-par for a long time (feature- and latencywise). Tight integration has its benefits if you can afford it (and apparently they can). So I guess as soon as they can get the same properties from RLS as from their own implementation they'd switch. But if it meant having to rewrite a lot of stuff that suddenly also becomes available to competitors that seems like a dumb move.

iudqnolq 6y ago
Their code is open source (if tightly linked to their codebase, of course) https://github.com/intellij-rust/intellij-rust https://github.com/intellij-rust/intellij-rust

matsemann 6y ago

I can think of multiple reasons they may prefer doing it themselves: Differentiation, if they just reuse the same thing everyone else does, they will have no moat or extra features. Or maybe because the language server protocol cannot handle everything IDEA normally provides, so they will have to run some kind of parser etc. on their end anyway. Or that interfacing with an external tool can be buggy or have weird boundaries making certain features harder to implement.

deleted 6y ago

[deleted]

specialp 6y ago

Besides Typescript, I haven't seen any language server do better in syntax completion and introspection better than the JetBrains equivalent. They probably don't want to work on it because 1. If they write their own they can make it work to exactly what they need, and 2. They would probably not leverage as much working on the OSS version as they'd lose by open sourcing and doing the bulk of the work on what makes them money. That might sound cold but it is not unreasonable.

iudqnolq 6y ago
It's MIT licensed https://github.com/intellij-rust/intellij-rust https://github.com/intellij-rust/intellij-rust

tsimionescu 6y ago

JetBrains have always developed their own language analyzers from what I've seen. I would bet they have a clear API between a language analyzer and their suite of refactoring and code navigation tools, and it would probably end up being similar to work to support that API through an open source variant VS building their own. Not to mention, JetBrains typically are at the forefront of IDE support for a language, they start working on it before there are any open source tools around to base work off of. Even with mature languages like C#, the JetBrains C# language backend predates Rosslyn by a good decade I think.

surajrmal 6y ago

There is nothing inherently wrong with solving a problem multiple ways. While it's usually good for smaller players in a space to work together, I'm always happy to see others that trod their own path. They can make different choices/tradeoffs, and learn from each other. This usually leads to better outcomes for both of their user bases.

dagmx 6y ago

I use both VSC and CLion, and CLion is a much better experience for Rust IMHO. I know the IntrlliJ only plugin is kind of lacking versus the CLion feature with regards to debugging, but overall I find CLions support to be miles ahead of rust analyzer for stability, speed and ease of use.