Hacker News Reader

Comment by matsemann | Hacker News Reader

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.

View on HN

> 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-_-...

[1] https://insights.stackoverflow.com/survey/2018#development-e...

[2] https://insights.stackoverflow.com/survey/2019#development-e...

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.

And you also have to see that they're just special purpuse branded IntelliJs that you can buy for less money.

We have had licenses for WebStorm, PyCharm and IntelliJ Ultimate depending on what the Dev in question was doing in his job. So some of that market share/use is hidden.

Why is it an advantage being Electron? If anything, IDEA is also cross-platform. As for speed, VSC is faster as a text editor, but not that much faster for IDE stuff if you try to use it as that. Even slower some times, maybe LSP incurs some overhead IntelliJ don't have to do.

While I get the point of LSP, as I wrote in another comment an IDE is much more than understanding the AST of the language and providing autocomplete.

I don't get your point about usage. What is it supposed to show? Even though VsCode is growing fast, JetBrains products are also growing and thus has a merit to them?

Usage is important, has all editors live and die by their community. Intellij is less dependant on them, as they develop their most important features themselves, but third-party plug-ins are still mandatory nowadays.

That's my take, anyways. I'm biased as I personally wouldn't use Intellij if not for the community that made Emacs mode plugins for it. I also tend to costumize more than your average programmer.

But tooling becomes broader and more complex year after year (too complex, maybe), so I don't see in the futur any company being self sustained on that front.

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.

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

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.

rust-analyzer is not a compiler. They plan on sharing a lot of code though.

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.

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.

> 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.

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

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.

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.

It's MIT licensed

https://github.com/intellij-rust/intellij-rust

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.

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.

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.

> 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.

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

Reply on news.ycombinator.com