Honestly, Jetbrains tout their flagship product - IntelliJ - as this top-of-the-range Java/Kotlin IDE yet they can't ship a stable product to save their lives. From constant indexing to foobared filesystem access lockups no other ide/editor I've ever used requires as much fixing, patching and monitoring for excessive resource usage.
> Honestly, Jetbrains tout their flagship product - IntelliJ - as this top-of-the-range Java/Kotlin IDE yet they can't ship a stable product to save their lives.
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?
Similar story for me, except it's Rider I use daily - it's been absolutely rock solid for me (way more than Visual Studio, that's for sure), for all the years I've used it. I've been seriously impressed with the JetBrains team for always releasing such solidity, despite it being such a complex product.
There can be some errors if I try an EAP version, but that's expected of course.
I remember when rider first came out, it was such a breath of fresh air performance wise compared to visual studio.
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
> Could you please elaborate and point out real world examples that showcase any instability you implied?
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.
> It's hard translate anecdotes into evidence for things like this without dedicating a bunch of time to it
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 get what you're saying, but I've been using JetBrains' products for about a decade (IDEA / Rider / CLion) and have run into my fair share of annoying bugs. A search inquiry into the the vast majority of them (by error messages or vague descriptions of the problem) usually finds an item in their bugtracker that's been sitting there from many months to many years without any obvious signs of activity (despite ACKs from the developers and multiple me-toos from the users).
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.
Well this is an HN comment section not a serious attempt at solving the problem. I have no reason to try to convince you, nor the inclination to produce a satisfying argument. But perhaps you should be less dismissive of people claiming things on here if for no other reason that it's kinda toxic and unpleasant.
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 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"?
I've seen this happen to people and I'm guessing they're running into bugs. I have multiple open projects at once and it works amazingly well with rather huge projects. It's smarter than any IDE I used.
The one problem is that the UI is a bit out of date because of Swing. Fleet is solving that problem.
They have done a ton of work and it is so much faster with almost every release. Yes indexing is slow, but it goes through a ton of things and it does it really quickly for what it does.
Try running an older version side by side if you think it's been getting faster. For example, any 2018.* is so much quicker compared to any recent version it feels like a completely different product. It also doesn't lose and rebuild indexes two times a day, and has fewer annoying bugs that "will be fixed in the next release" for the past two years. Unfortunately, I do need support for the latest Java version, or I'd move right back.
I thought I was going crazy. The reindex frequency is so much higher than it used to be. AppCode is worse than IntelliJ in this regard and building Swift indexes for Cocoapods is unimaginably slow.
Its a drawback, yes. But not a deal breaker for most people. Most professional users have good RAM and SSD, and start IntelliJ maybe once a day. It's "Good Enough ™"
I have 64gb of ram and Webstorm still freezes for 15+ seconds sometimes. It's not GC, it's not memory, not plugins, just random bugs or filesystem access blocking UI updates etc.
I wrote plugins for most IDEs including JetBrains. If you hold the EDT they block your plugin. There's no way a core plugin allows that. I'm guessing this is some other bug, did you file an issue with your logs?
I read through the logs and they didn't show anything very helpful. Every time I ran profiling tools on it, it never occurred so I haven't created a ticket yet ... :)
That’s just the jetbrains releasing an old runtime (11) with an even older GC and relatively low max heap size. Just simply bumping the heap size up helps, but changing it to G1GC with a lower target pause time and adequate heap size will make it so much smoother. But if you can then change to a newer runtime and use ZGC which has basically no pause whatsoever.
The unfortunate effect of it being a JVM product is that you need to tune GC and memory setting because defaults are made for people having 8GB of RAM.
How does excessive resource usage mean their product is unstable? It's a pity if the performance is bad, but I would think stable means there are little to no major breaking bugs that get in the way, and if they do an IDE restart usually fixes things.
They literally broke all plug-ins for months because of a regression in stripping white space from config files. The whole product is incredibly poorly tested and is only dominant because it’s the least terrible.
