Reflections on IDEA vs VS Code

Intellij offers a lot of custom behaviours that IMO programmers start coding the "Intellij way" (let's call it Intellij muscle memory for lack of a better definition) on the other hand going from vi to Emacs to Sublime to VSCode is less of a problem and people tend to honestly judge strength and weaknesses of each one.

For example magit is so good (for me) that until the magit plugin for VSCode came out I kept an instance of Emacs running only to interact with the git repository.

Intellij git integration in comparison, in my opinion, it's barely usable and generally counter intuitive.

BTW the java plugin bundle for VSCode replicates 95% of the features of Intellij, except for some formatting styles and a few of the refactoring facilities that I could not reproduce, I switched from Intellij to VSCode without looking back. There's even a keyboard bindings plugin for VSCode that perfectly maps IJ keyboard shortcuts.

If only the VSCode java ecosystem was refined as it is today 2 years ago when the project I am working on started, I would have never even downloaded Intellij.

If I had an euro for every time I had to "Invalidate cache and restart" on Intellij to make it recognize some trivial change, I would be rich now.

Having said that: they are different products for different targets.

Intellij has a huge advantage in corporate environments where conformity, uniformity and easily replacing team members are paramount, VSCode is an highly customizable code editor that fits a different use case where each member of the team prefers to customize the working experience as much as possible.

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.

>>>>>>>>>>>>>>>>>>>

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.