I buy a product to do a task. I have a Java making machine called a computer. I don’t care how much of the product it uses. As long as it performs the task. Anyone has used it knows there is simply no substitute. And I don’t care about every 4 years expensing a new laptop. Nobody has ever even acknowledged it.
AppCode by JetBrains indexes like mad. I have a high specced MBP, it can randomly take 10 minutes to re-index on start. Change target device from iOS to simulator – reindex. Change to macOS catalyst – reindex. Change back to native iOS target – reindex. AppCode can be great when it actually works, which has become rarer and rarer over the past two years.
It’s so bad that I got a refund and now use Xcode. IMO Xcode is one of the worst IDEs. But at least, outside of Xcode’s garbage update processes (which impact AppCode), it doesn’t randomly halt my workflow for 10 minutes at a time.
I don’t think this is a problem that a new machine should solve. The software shouldn’t degrade in quality this much over time.
It does the task properly and effectively just not most efficient. Unfortunately no other IDE comes close to it features/polish so we have to live with it inefficiencies.
They decided to code their own analyzers for some languages like Scala and Rust instead of relying on the support provided by the compiler frontend through the language server protocol. Result: Intellij idea has endless "good code red" problems, it doesn't detect all compile problems, it still can't expand macros properly and autocomplete does not work at all with more advanced libraries. While generally it kinda works most of the time with simple code now, it is still far from the polish that VS Code and editors based on official language servers offer in this area.
> Intellij idea has endless "good code red" problems, it doesn't detect all compile problems,
Doesn't this just means that IntelliJ, being an independent implementation, flags problems that a compiler frontend doesn't, and vice-versa?
That's hardly a problem, isn't it? I mean, sometimes even compilers that serve as reference implementations fail to properly support some language constructs. Case in point, look at how GCC handled C++11, and how some features were only supported a couple of years after the standard was approved.
> it still can't expand macros properly and autocomplete does not work at all with more advanced libraries.
Arguably, IntelliJ (or any IDE) shouldn't expand macros at all, and "more advanced" is codeword for "uses obscure features in non-trivial ways". Those are hardly problems.
> Doesn't this just means that IntelliJ, being an independent implementation, flags problems that a compiler frontend doesn't, and vice-versa?
No, it often flags perfectly correct (compiling and working) code. Search for "good code red" on their bugtracker - this is going on for years. Many of those problems are because Intellij type inference infers a wrong type, then it can't resolve a method or field because it's looking it up in the wrong place. Or it misses the stuff expanded from a procedural derive macro.
The fundamental problem is, in order to make it work correctly they have to reimplement the whole compiler frontend, which is a very ambitious goal, and they likely don't have resources to do that for the many languages that Idea wants to support.
> Arguably, IntelliJ (or any IDE) shouldn't expand macros at all, and "more advanced" is codeword for "uses obscure features in non-trivial ways". Those are hardly problems.
Macros and metaprogramming are not obscure features - those are the core features that often make basic stuff work like serialization, database access, command line argument parsing or data formatting. While the libraries might be sometimes internally complex, they are often way easier to use than the counterparts in languages with no such support.
> No, it often flags perfectly correct (compiling and working) code.
"Compiling and working code" does not mean it's valid or acceptable code. Implementations can and often are buggy, or push implementation-defined behavior which is unacceptable. This code should be flagged appropriately. Case in point, C++11 support in GCC 4.8, and how "compiling and working code" in GCC4 broke horribly in subsequent releases.
> Search for "good code red" on their bugtracker - this is going on for years.
I fail to see how this is a good or reasonable test. A cursory search shows up only indexing problems, fixed by invalidating the cache, which bear no resemblance with language support.
> Compiling and working code" does not mean it's valid or acceptable code.
In safe Rust and Scala it means it is valid, modulo bugs in the compiler, which are rare. Also I'm really talking about code that is obviously ok - e.g. there exists a function on given type, yet idea fails to see it.
> do you actually have any concrete example?
In both of my Rust projects, which are pretty tiny (<5k loc) there are a few instances of good code red issues or fragments where the type inference gave up (no error flagged, but also no autocomplete). Will report those.
I reported plenty of such issues earlier to the Scala plugin, and got tired a bit.
> code their own analyzers for some languages like Scala and Rust instead of relying on the support provided by the compiler frontend through the language server protocol
Because IDEA doesn't support LSP. Because IDEAs analyzers are not external entities running in an external process and communicating in JSON over HTTP.
It doesn't support LSP - that reads: it is not polished, or sometimes hardly even works for a bunch of languages that other IDEs and editors work fine with.
BTW: I'm not saying it is bad or doesn't get the job done for a selected set of languages. I'm only referring to the "polished more than the other IDEs" bit in the OP comment. It is kinda love-hate relationship to me. Not polished, but we can live together ;)
LSP is hardly polished for the majority of languages either. Sometimes Intellij’s support is much better, eg. afaik people like writing Rust with Jetbrains’ tools.
Most (all?) LSP implementations are open source. If the same effort they put into reimplementing the compilers went into making better LSP-based solutions, LSP would run circles around custom plugins, because LSP has accurate data from the official compiler. However, I guess I know why they are not doing that: because that would benefit the competition as well.
And yeah, obviously Java story is definitely polished, but it has been under development for decades, and also Java is quite a limited language.
Actually, Microsoft's Python LSP for VS Code is proprietary[1] (as are some of their other extensions) whereas PyCharm Community Edition is open source[2].
What about other things external to the compiler like immediately recognising and mapping project configs and structures (for example, Spring, or Symfony, or...)?
Or things like "version X of the language introduces new things and we can automatically refactor your code to reflect the new ways of dealing with things"?
