I use IntelliJ and Clion daily and I have never noticed any sort of instability.
I used to experience long indexing times until I learned that I chronically misconfigured projects and included build and autogenerated dirs in the index, which is trivially solved by excluding them and invalidating the cache. We're talking about something you do once right after you import the project.
The only foobared filesystem issue I ever stumbled upon was when I toyed with junctions pointing to a RAM drive on Windows, and Clion left the junctions out of the project view.
And that was it.
Could you please elaborate and point out real world examples that showcase any instability you implied?
There can be some errors if I try an EAP version, but that's expected of course.
Haven't done any c# in a while now so unsure if that's still the case but make heavy use of all the other tools and happily pay my yearly subscription.
There's occasional glitches, recently datagrip (the database ide) has sometimes got itself into odd states where it's loading the data sources infinitely, but overall I find them stable and performant products
When working with typescript, it’ll still index your packages even if you’ve excluded it because it needs it for autocompletion (I assume).
It's hard translate anecdotes into evidence for things like this without dedicating a bunch of time to it -- either to tracking down bugs or other users, or carefully making sure that you have eliminated any project-specific problems or misconfigurations.
So I agree with the parent that Intellij products seem to be quite glitchy and to have chronically bad performance, but I haven't put the time in to fully understand why so I doubt I could convince you.
This is how any credibility breaks down. Posting a bug report takes as much time as posting a message on HN.
Moreover, if these problems were so eggregious and so frequent as claimed, wouldn't you be more motivated to post something about them in order to get them fixed? I mean, most of jetbrains' product line is only available to paying customers.
But alas no example is given. Not even a faint description of what the problem felt like. Just a blanket accusation that the world-leading IDE company is unable to ship a stable IDE.
I still prefer JetBrains' IDEs, but they are extremely glitchy. It's just a fact of life if you've spent any significant amount of time in them. They seem to just not care about performance and bugs the same way they care about churning out new features.
Anyway, maybe the number of posters who are complaining about Jetbrains products on here is evidence to you that our issues are not, in fact, imagined.
Also, as the other commenter said, there are always open issues when I go look for the things that I'm experiencing. That doesn't chain the experience on my side.
I use IntelliJ, Clion, Datagrip and sometimes Rubymine if I need to touch Ruby code and it's pretty good.
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.
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.
https://gcc.gnu.org/projects/cxx-status.html
> 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.
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.
"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.
Do you actually have any concrete example?
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.
Because IDEA doesn't support LSP. Because IDEAs analyzers are not external entities running in an external process and communicating in JSON over HTTP.
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 ;)
No, it doesn't read like that.
> sometimes hardly even works for a bunch of languages that other IDEs and editors work fine with.
LSP is as much a hit-and-miss. And it's definitely not polished, let's say, for Java.
And yeah, obviously Java story is definitely polished, but it has been under development for decades, and also Java is quite a limited language.
[1] https://visualstudiomagazine.com/articles/2021/11/05/vscode-...
[2] https://github.com/JetBrains/intellij-community/tree/master/...
If, and only if the official compiler is actually designed to support compiler-as-a-service etc. And this only begins to scratch the surface.
Let me introduce to a nearly unending and continuously expanding list of refactorings alone in IntelliJ: https://www.jetbrains.com/help/idea/refactoring-source-code....
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"?
Or...
The one problem is that the UI is a bit out of date because of Swing. Fleet is solving that problem.
Did you ask in their developer slack group?
They are VERY responsive.
[1] https://docs.oracle.com/javase/8/docs/technotes/guides/swing...
[2] https://docs.oracle.com/javase/8/docs/api/javax/swing/Repain...
The big thing about VSCode that I really like is that it just seems to be easier to look at... There's less visual cruft by default than in IntelliJ.
Edit: Not to say that I'm right or that you're wrong. Just pointing out differing opinions exist. To each their own.
VSCode shines in comparison only when all you need is a text editor to quickly open a couple of files, you don't need to do anything beyond reading code without navigating files or doing the occasional typo fix, and you don't actually need an integrated development environment.
Other than that, I struggle to come up with a scenario where, if anyone already had both installed, vscode would be the preferred solution.
My IJ is set up in a way that it is very clean. Tabs, file explorer, editor, embedded terminal if needed. It doesn't get much cleaner.
I guess the MacBook Pro's days are numbered, then?
I guess stability, tooling ecosystem, and ages of user/customer support info means nothing then, and being new is reason enough to scrap all your tooling and workflow?
Developers are paid to deliver features, and test-driving the latest and greatest fad gets in the way.
I use VSCode on par with IntelliJ and Clion and I wouldn't put VSCode ahead in the performance department. In fact, until a few months ago VSCode suffered from a rather eggregious performance problem caused by the pathological way that intellisense scanned files that rendered it unusable with some projects. We're talking about full blown hangs which led to forced restarts. In fact, I find the jab quite funny because IntelliJ's main performance issues are also tied to file indexing, but here I see vscode being portrayed as behaving better?
Both IntelliJ and vscode are great at what they do, and their main usability issues stem from the same type of feature/problem. Why try to one-up either of them?