5 ms·

Most of this post is just speculation like "I seriously doubt it will work well in an average cafe though" without much substance. Either test it or report on i

Most of this post is just speculation like "I seriously doubt it will work well in an average cafe though" without much substance. Either test it or report on it, or at least discuss its shortcomings based on some technical merits. And frankly I don't care how well it works on "spotty café wifi". If the wifi sucks I wouldn't sit there and work anyway. As for the language server protocol, nothing stops IDEA from doing the same. But while technically cool, it really doesn't matter as long as my programming language of choice works. I don't care how it works. In my anecdotal example, the community made Elm plugin for IDEA was even for a long time miles ahead of the one for VSC.

superdimwit 6y ago
Exactly, and I don't see how it would work any less well in a to café than VScode remote SSH.
charrondev 6y ago
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.
monsieurbanana 6y ago
> Most of this post is just speculation like "I seriously doubt it will work well in an average cafe though" Meh. I don't think that's his main point. The two advantages of vscode he points out are: - browsers, and by extension Electron, are the best funded cross-platform GUI - vscode offloads language support to compilers (or other third-party tools) via LSP (Language Server Protocol) Electron apps are... slow craps. But it seems to be a problem of implementation, as vscode is slick and fast. In my own anecdotic experience, faster than IDEA. As for LSP, you don't care how it works, since it works now. But will it support as many languages as vscode in the future? Sure, that's speculation, but he gives a sound argument: it offloads the burden of maintaining the language integration to the community at large (or even to the language team itself). By creating a LSP server, you add support for vscode, vim, emacs, or even... Intellij. Hard to pass. LSP support on Intellij is a community plugin, far from first-class experience. And if it does become first-class, why then would people choose it over vscode? If both are LSP based, vscode is faster, free, and extensible in the most widely used language. And here's something less speculative, editor usage from stackoverflow surveys: - 2017[0] -> vscode 24.0% intellij 23% - 2018[1] -> vscode 34.9% intellij 24.9% - 2019[2] -> vscode 50.7% intellij 25.4% Disclaimer: I don't think LSP is great, yet. Most of the servers are still rough around the edges, but as an emacs user, I have big hopes for them. [0] https://insights.stackoverflow.com/survey/2017#technology-_-most-popular-developer-environments-by-occupation https://insights.stackoverflow.com/survey/2017#technology-_-... [1] https://insights.stackoverflow.com/survey/2018#development-environments-and-tools https://insights.stackoverflow.com/survey/2018#development-e... [2] https://insights.stackoverflow.com/survey/2019#development-environments-and-tools https://insights.stackoverflow.com/survey/2019#development-e...
- arcturus17 6y ago
  It's important to note that IntelliJ is not Jetbrains' only product. PyCharm has seen a very significant growth during this period too (7.7% -> 13.4%), although PHPStorm has decreased (11.6% -> 7.6%). Regardless, I find it remarkable that IntelliJ hasn't lost an inch of ground (it's even made modest gains) despite VSCode's explosion.
  - 6y ago
dgellow 6y ago
> And frankly I don't care how well it works on "spotty café wifi". If the wifi sucks I wouldn't sit there and work anyway. Obviously the author cares about it. It’s basically an article from a personal blog, what makes you think that the author should write for your own use instead of theirs? They are sharing their thoughts on the topic, and that’s it.

superdimwit 6y ago

Exactly, and I don't see how it would work any less well in a to café than VScode remote SSH.

charrondev 6y ago

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.

monsieurbanana 6y ago

> Most of this post is just speculation like "I seriously doubt it will work well in an average cafe though" Meh. I don't think that's his main point. The two advantages of vscode he points out are: - browsers, and by extension Electron, are the best funded cross-platform GUI - vscode offloads language support to compilers (or other third-party tools) via LSP (Language Server Protocol) Electron apps are... slow craps. But it seems to be a problem of implementation, as vscode is slick and fast. In my own anecdotic experience, faster than IDEA. As for LSP, you don't care how it works, since it works now. But will it support as many languages as vscode in the future? Sure, that's speculation, but he gives a sound argument: it offloads the burden of maintaining the language integration to the community at large (or even to the language team itself). By creating a LSP server, you add support for vscode, vim, emacs, or even... Intellij. Hard to pass. LSP support on Intellij is a community plugin, far from first-class experience. And if it does become first-class, why then would people choose it over vscode? If both are LSP based, vscode is faster, free, and extensible in the most widely used language. And here's something less speculative, editor usage from stackoverflow surveys: - 2017[0] -> vscode 24.0% intellij 23% - 2018[1] -> vscode 34.9% intellij 24.9% - 2019[2] -> vscode 50.7% intellij 25.4% Disclaimer: I don't think LSP is great, yet. Most of the servers are still rough around the edges, but as an emacs user, I have big hopes for them. [0] https://insights.stackoverflow.com/survey/2017#technology-_-most-popular-developer-environments-by-occupation https://insights.stackoverflow.com/survey/2017#technology-_-... [1] https://insights.stackoverflow.com/survey/2018#development-environments-and-tools https://insights.stackoverflow.com/survey/2018#development-e... [2] https://insights.stackoverflow.com/survey/2019#development-environments-and-tools https://insights.stackoverflow.com/survey/2019#development-e...

arcturus17 6y ago
It's important to note that IntelliJ is not Jetbrains' only product. PyCharm has seen a very significant growth during this period too (7.7% -> 13.4%), although PHPStorm has decreased (11.6% -> 7.6%). Regardless, I find it remarkable that IntelliJ hasn't lost an inch of ground (it's even made modest gains) despite VSCode's explosion.
- 6y ago

dgellow 6y ago

> And frankly I don't care how well it works on "spotty café wifi". If the wifi sucks I wouldn't sit there and work anyway. Obviously the author cares about it. It’s basically an article from a personal blog, what makes you think that the author should write for your own use instead of theirs? They are sharing their thoughts on the topic, and that’s it.