Running IntelliJ Idea with JDK 17 for Better Render Performance with Metal | Hacker News Reader

Running IntelliJ Idea with JDK 17 for Better Render Performance with Metal

mustafaakin.dev

182 pointsCSDude197 comments

If anyone is interested why this is even a thing, you can see here [0] how every change in the IDE repaints whole window, thus eats CPU like mad. On the MacOS with external 4k+ monitor, this really tanks even macpro, like there is no GPU acceleration at all and everything is rendered by the CPU.

[0] - https://photos.app.goo.gl/fsxgEHXCsTzKL37w7

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.

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.

So by "least terrible* you mean it's the best?

Well there's an intentional connotation of it still being bad which 'best' doesn't capture.

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.

I would not be surprised if you don't care if product you bought do task properly or effectively.

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.

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.

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

Do you actually have any concrete example?

> 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 ;)

> It doesn't support LSP - that reads: it is not polished

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.

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

[1] https://visualstudiomagazine.com/articles/2021/11/05/vscode-...

[2] https://github.com/JetBrains/intellij-community/tree/master/...

> LSP would run circles around custom plugins, because LSP has accurate data from the official compiler.

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

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.

They've had their analyzers years before the concept of a LSP even existed.

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.

While I agree with you in principle, it sure sould be nice if Jetbrains IDE’s didn’t become nearly unuseable while indexing.

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 ™"

Or just once till next restart, Just Close the Lid ™.

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?

Did you ask in their developer slack group?

They are VERY responsive.

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.

It's not GC. It's nowhere near using the max memory available to the JVM.

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.

I have the limits raised. It's not GC or memory related.

The IDE is more than two decades old. Cut them some slack?

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.

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.

> 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

Same. I had issues back in the day with HDD speeds, but since going to SSDs over 6?+ years ago and now NVME it flies.

I use IntelliJ, Clion, Datagrip and sometimes Rubymine if I need to touch Ruby code and it's pretty good.

NVME might be the greatest advancement ever in terms of noticable speed improvement. SSD was alright, but I wasn't blown away by it.

Don't worry, the new performance budget will be eaten soon enough.

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

Er, *change, not change.

Switching a git branch is also a great way to kick off reindexing.

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 hilarious how the same people that talk shit about VSCode being too slow use IntelliJ instead

For Java there really is no replacement for IntelliJ. I don’t think people “talk shit”. I use vscode and I enjoy it. I don’t use it for Java.

VSCode supports Java, and can do 99% of what IntelliJ does in a simpler, faster interface. https://code.visualstudio.com/docs/java/java-tutorial

Do you do Java for a living? I do and nobody in the industry uses vscode for Java. IntelliJ has a unique position like eclipse did 10 years ago that every senior person uses it and loves it. Vscode for Java I’m sure is fine. Never used it. So not saying it’s not good or not suitable for tasks.

“Everyone in the industry uses it” is always the argument for some legacy tool before it’s replaced by something better. Case in point, Eclipse like you mentioned yourself.

> “Everyone in the industry uses it” is always the argument for some legacy tool before it’s replaced by something better

I guess the MacBook Pro's days are numbered, then?

> “Everyone in the industry uses it” is always the argument for some legacy tool before it’s replaced by something better.

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.

Once the alternatives does even a fraction of what Intellij provides out of the box..

Name one major feature that IntelliJ has that VSCode doesn’t.

Before everything more important, maybe vscode should fix their auto complete. The suggestions are so bad, I'd turn it off before using it for anything serious.

Any number of complex refactoring, code upgrade refactoring, symbol search etc.? Knowing how to work with project configs (such as Spring, Micronaut, and non-java projects like Symfony etc.)?

Eclipse users loved it 10 years ago? Man, I think I started using Eclipse 15 years ago, and every year would get excited when hearing about the new release because I would be hopeful that they finally made it perform better. They never did... I was so happy when I finally found out about IntelliJ. It's a significantly better experience than Eclipse ever was.

Yes - Eclipse was the best Java IDE once upon a time and I loved it! It was far superior to its contemporaries (Netbeans!). I have fond memories of the Indigo release, which was one of the last versions I used before switching to Jetbrains

I do Java and Scala for a living. VS Code is perfectly fine, it runs eclipse underneath. I use both it and IntelliJ for my work. IMO the only area where IntelliJ shines is debugging, and support for more rare libraries like play and sbt.

I do Java for a living, and I use VSCode and IntelliJ both for Java. VSCode shines when you want to quickly open up a project and do something minor. IntelliJ is better for when you're going to be there for a while.

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.

Funny, I have the reverse opinion. I think VSCode's UI is obtuse and the default theme is awful. I will agree that IntelliJ's UI is busy but I know where all the tools are. Reminds me of Photoshop in that regard. I appreciate not needing to frankenstein together a ton of plugins just to get non-trivial functionality.

Edit: Not to say that I'm right or that you're wrong. Just pointing out differing opinions exist. To each their own.

You will LOVE Fleet. It looks like VSCode, loads faster than it... Yet you can activate "smart mode" which is the full power of IntelliJ. Pretty cool. Still early so a lot of things aren't there yet but I think it will be a huge deal.

> VSCode shines when you want to quickly open up a project and do something minor.

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.

I agree with 'by default' but you can hide it all, even go as far as having nothing but the text visible in the window.

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.

No, it can't, because it's understanding of Java code is much worse.

I'm not a Java developer so forgive my ignorance, but is Eclipse as good as IntelliJ?

Sadly no, as Eclipse was an admirable project at the time. But IntelliJ has far outpaced them years ago. I used them side by side in maybe 2016 for a while, and it was just no comparison. Since then IntelliJ is still making leaps, and Eclipse is just hanging by a thread.

> It’s hilarious how the same people that talk shit about VSCode being too slow use IntelliJ instead

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?

I use both. Both make me sad. You know what doesn't? Notepad++. But I haven't used it for "real" programming with debugging cycles etc.

Could this be because of the double-buffering[1] that Swing is doing? I can't find any setting to turn it off, but you can do it in code[2] with a method on RepaintManager.

[1] https://docs.oracle.com/javase/8/docs/technotes/guides/swing...

[2] https://docs.oracle.com/javase/8/docs/api/javax/swing/Repain...

If you use a HDPI screen, e.g. retina, external 4-5K screen, just turn off anti-aliasing in the IDE options.

It renders a ton faster and you won't see the difference, because you need anti-aliasing when 1px=1px, you don't when it's subpixel anyway.

That's not how anti-aliasing works! Essentially all digital screens benefit from anti-aliasing, irrespective of the resolution. Even if you had a screen with an absurdly high resolution, such as 38,400 × 21,600 ("40K"), without anti-aliasing you'd still get issues like moire patterns and shimmering when viewing highly detailed content with regular patterns.

However, past a certain point, the benefits are less noticeable, whereas the overheads of AA increase to absurd levels. Trying to super-sample an 8K game will still bring the best GPUs in the world to their knees.

Dumb question here. Why is this necessary? Does Jetbrains not include their latest Jetbrain Runtime release in their IDE builds?

Or maybe Jetbrains Runtime releases run a bit ahead of what gets bundled in with the various Jetbrains IDEs?

Jetbrains includes JBR11 by default.

For now, Java 17 has only been out for a few months. They'll likely switch with their next major release. 17 and 11 were both LTS releases.

I've used Intellij for quite some time and there has always been quite a bit of magical thinking surrounding the performance topic that stems from a poor understanding of how things work, broken assumptions about how things should work, and so on.

Intellij has lots of performance baggage. And addressing this and overstating the effects of mitigations is a long standing tradition in release notes. Despite numerous supposed fixes and improvements to the IDE, compiler, etc. even in just the last year, I still find myself waiting for it to do whatever for minutes on end every day. A half minute recompile after a 1 character code change.

Rendering, garbage collection, and other things people like to point at are not even close to being a root cause for this. The real cause is that it simply does a lot of work and moves around a lot of data. The edge cases where that just requires noticeably slow re-computation happen a lot and when they do, things get slow.

It is recommended to use the currently bundled JBR version (JDK 11). Although later versions are available for testing, they are less stable as the author of this blog post mentions at the end.

JetBrains' attitude to this has been horrendous.

Try running their products on a more recent JVM. They are actually usable and don't leave you feeling like you've been thinking in molasses. Ironic for a company called "jet" brains.

They (JetBrains) have been actively fucking a portion of their (one would think, technically savvy) customers by not giving them the most responsive system they can to run, then acting all paternalistic and gaslighty by saying "oh we don't recommend you use anything other than the one we ship." [1] when people complain.

Listen, JetBrains: I have wasted enough time (while my thoughts race ahead trying to work on my projects) sat on my phatass 64Gb NVMe-equipped Xeon, nvidia (native driver) Debian workstation waiting for pycharm et al to mooch along like at a stately pace redrawing the screen like it's a 1994 486 with an HDD. In the end my thoughts stopped racing and I began to think, yeah, well, I just gotta endure it... and then asking myself if I'm alone in this particular slow-motion hell-hole or is the world really like this?!

Once I had got to the bottom of it (notes here https://iam.georgecox.com/2021/11/24/making-jetbrains-ides-r...) I _instantly_ began to regain the feeling of fluidity of thought in my work. It was the biggest single productivity gain I've made in the past year, and I have had zero stability problems. Some debugging features are not available, but I haven't missed them.

At this point JetBrains would do well to take a leaf out of Apple's playbook from 2009 when they shipped the Snow Leopard release (Yes I am one of those that thinks that Snow Leopard was the best release of Mac OS X...) which concentrated solely on quality and speed, and no new features. [2]

Thank you for your attention. Merry Christmas ;-)

[1] a fact which gets parroted around various fora without any understanding of the problem because "it works on their computer" It seems that much of the improvements are for the benefit of MacOS X users, while the policy of sticking with a version 11 JDK is to the detriment of users on other platforms.

[2] quality and speed are features, too!

Not sure what your problem with them is.

JetBrains is simply trying to provide a stable development platform.

And since it took me about about a minute to switch to JDK17 it's not like they are going out of their way to make it difficult.

Not sure what your problem with them is.

I explained it in full above.

And since it took me about about a minute to switch to JDK17 it's not like they are going out of their way to make it difficult.

When you restarted in JDK17 you didn't get any access errors? What app, OS, and JDK vendor is this?

If you look in the post, they explain what flag they use to avoid those access issues.

I am sorry to hear about your productivity issues. I also experienced some slowness in recent builds, although I think our issues are not directly related, since I primarily use IntelliJ IDEA and not PyCharm. Following a recent issue I encountered on JDK 17, I was also advised to downgrade to JDK 11. [1] I think maybe they are waiting until JDK 17 is more stable for release, but anecdotally speaking, JDK 17 runs pretty well for me on osx-aarch64, save for a few minor hiccups. If the issue you are experiencing is a persistent one, you might also consider reporting a performance problem [2].

I've heard good things about JetBrains Fleet. [3] Although it has not yet been released, it seems to have many of the same features as the full IDEs and is more responsive in the editor department. Anyhow, I hope your experience improves and you have a Merry Christmas as well!

[1] https://youtrack.jetbrains.com/issue/IDEA-278926#focus=Comme...

[2]: https://intellij-support.jetbrains.com/hc/en-us/articles/207...

[3]: https://www.jetbrains.com/fleet/

I'm doing fine now -- PyCharm and IDEA benefit greatly from using JDK16. Remember, I'm on Linux, you're on OSX where they had to make some font changes which, AIUI, are Mac-specific, and it seems like that has made them decide to stick with JDK11.

I will update the post I made on my blog with the JVM options for JDK17. [1]

I have had mixed success reporting bugs to JB, as is to be expected for a company their size.

[1] it's Christmas, so why wait... it's this lot

    --illegal-access=warn
    --add-exports java.desktop/com.apple.eawt.event=ALL-UNNAMED
    --add-exports java.desktop/com.apple.eawt=ALL-UNNAMED
    --add-exports java.desktop/com.apple.laf=ALL-UNNAMED
    --add-exports java.desktop/sun.font=ALL-UNNAMED
    
    --add-opens java.base/java.lang=ALL-UNNAMED
    --add-opens java.base/java.util=ALL-UNNAMED
    --add-opens java.desktop/java.awt.event=ALL-UNNAMED
    --add-opens java.desktop/java.awt.peer=ALL-UNNAMED
    --add-opens java.desktop/java.awt=ALL-UNNAMED
    --add-opens java.desktop/javax.swing.plaf.basic=ALL-UNNAMED
    --add-opens java.desktop/javax.swing.text.html=ALL-UNNAMED
    --add-opens java.desktop/javax.swing=ALL-UNNAMED
    --add-opens java.desktop/sun.awt=ALL-UNNAMED
    --add-opens java.desktop/sun.font=ALL-UNNAMED
    --add-opens java.desktop/sun.swing=ALL-UNNAMED

I previously used IntelliJ IDEA on Linux for over eight years, so I can sympathize with your struggles. [1] Recently I started using OSX because my Thinkpad finally died and I could not find another laptop I liked. So far, it's been pretty bumpy, although I noticed that some things have improved (like fonts and build times). The downside is that many things currently do not work on aarch64 right now, and I somewhat regret making the switch this early. I recently started writing some Haskell, which was a pain to setup on my local machine but now that GHCi and Stack finally support it [2], I think it's getting stable. Hopefully more native libraries will offer support for aarch64, because despite the minor speedups (faster JVM), overall it's been a productivity-killer. Very few native libraries provide M1-compatible builds right now.

[1]: http://breandan.net/2014/08/18/shell-script/

[2]: https://github.com/haskell/haskell-language-server/issues/20...

I tried this on my Intel Mac, using the JBR 17 (JCEF) download from Jetbrains. IDEA did start up, but the menus didn't work at all. The top-level menus were there, but they did not open any submenus. Other than that, things seemed to work. I wonder if there is a workaround.

> quality and speed are features, too!

So much this, the amount of people who refuse to believe this (even after a decent argument in favour) is infuriating.

The good thing with that kind of software is that you are not forced to use it and that there are a lot of alternatives adapted to everybody's preference. I'm happy to live in a world like that.

> JetBrains' attitude to this has been horrendous.

> Try running their products on a more recent JVM.

Isn't JDK17 literally two or three months old?

JDK17 was released on sep 17 2021. Meanwhile, IntelliJ 2021.2 was released on July 27 2021, and IntelliJ 2021.3 on November 30 2021.

Who in their right mind would dump a stable LTS release in favour of the latest and greatest in the middle of a point release? Specially on a production project which is expected to be rock solid, and quite possibly wouldn't be able to recover from a reputation hit caused by regressions introduced by hasty ill-advised migrations?

"more recent" does not mean "the most recent"

> "more recent" does not mean "the most recent"

JDK17 is the latest LTS release.

The previous LTS release was JDK11, which is already shipped with IntelliJ.

What, exactly, are you trying to argue?

What, exactly, are you trying to argue?

Disingenuous HN snark never stops; (re-)read the whole thread to find out what you've missed.

You literally write:

> Try running their products on a more recent JVM.

> ...

> while the policy of sticking with a version 11 JDK is to the detriment of users on other platforms.

The answer is, quote: "JDK17 is the latest LTS release. The previous LTS release was JDK11, which is already shipped with IntelliJ."

What exactly do you want of JetBrains?

Interim releases receive only 6 months of support. They'd have to switch the runtime version mid-flight, or leave users with an unsupported runtime, or dedicate a ton of resources to supporting JDK themselves (in addition to all the patches they do now).

JDK 11 would be fine, but why have such a bad default config for the JVM? They literally use a deprecated GC algorithm instead of the default and set a way too low max heap size (I guess so people don’t say that it uses too much RAM, but all it does is making the GC run constantly)

It's for people using 8GB ram laptops.

> while the policy of sticking with a version 11 JDK

JDK 11 is an LTS release. JDK 17 only shipped a few months ago.

As a personal anecdote: I tried to upgrade a small microservice to Java 17 from Java 11. It took me a week hunting weird bugs and obscure undocumented things that suddenly just broke.

But sure. JetBrains should drop everything and move to JDK 17 the moment JDK 17 ships because?... Because what exactly?

"more recent" does not mean "the most recent"

JetBrains' fork is not regularly merged, and is somewhat old at the moment.

In any other product, this would be a red flag. What is special about it? What unstable APIs have they used? If they've done that, what other things have they done?

Should every vendor ship their own version of the JVM?

I mean sure, in an ideal world one Java should work for everything. In practice, there are too many things that can go wrong with untested combinations. For better or worse, the world is moving towards bundled dependencies (Snap, Flatpak, Docker, etc). On my system, I see at least DBeaver and Arduino that ship their own JVM. I don't think it's a red flag.

Why do they do that in each case? Why do they need a specific version such that it it unreasonable for the regular user to have already in place?

If we look at something like Minecraft - it now bundles Java. This lets them upgrade java versions without bothering every 12 year old to figure out how to do that.

Good for them, but Minecraft is neither DBeaver nor Arduino.

Because as an industry we have collectively failed - both in dependency management and in version control. There are unreliable, and they are incomprehensible to an average user, no matter which operating system you use.

It is because of the strange belief that a piece of software can work reliably against a set of libraries when they were not tested together (just because somebody says they're compatible). Dependency management can work only if every piece of software is able to link directly to the versions of libraries to which they were originally released.

The dependency management must be of exact versions of libraries that must be present to work with the installed software. Instead, people believe that it is possible to manage dependencies by stated compatibility: this will never work.

If operating systems had dependency-library versioning, lookup, retrieval and verification facilities built directly into the core exposed with a proper C-API, all these problems could go away.

Our industry builds technology as advanced as jet engines, but with stone tools.

Because different releases are different. So just package up the releases you know work with your app.

Yeah imo while it’s pretty wasteful, I’m still in favor of this trend. Given the decreasing cost of storage, I’ll happily trade a bit of disk space for less wasted time on configuration, bugs, performance issues, etc.

Shipping your own JVM is actually the Oracle recommended way. It's why they created jlink to create your own minimal runtime and jpackage to create your installer with that image.

I wonder: Would the JDK17 GraalVM offer additional benefits?

Do you mean the Graal JIT compiler or AOT compiling? The former may at times be better at escape analysis, but I don’t think there would be a significant difference. Using an up-to-date GC implementation is already night-and-day (I use G1GC with slightly decreased target pause time and larger heap size. But ZGC would be probably the best for this use case)

I’m not sure whether Intellij could be AOT compiled, would be interesting due to faster startup time but AOT compiled binaries can be somewhat slower than what the JIT compiler is capable of.

Unless they would use Graal Enterprise I doubt AOT would perform better anyway. Graal Community uses the Serial GC for native image. Enterprise uses G1

I'm pretty sure AOT on Graal doesn't support swing anyways

ZGC is very good for IntelliJ. It’s fast.

ZGC can be enabled on all platforms as of Java 17 and maybe even earlier. I won’t use any other Java GC for any reason I can think of.

ZGC is available from JDK16, but is not compatible with AOTC, annoyingly, and the latter has been removed from JDK17. I have found that using AOTC for the java.base module makes IDE startup much smoother.

Ah, interesting. Thanks.

If useful: ZGC has actually been available on different platforms in earlier Java releases. Linux, Windows, and macOS didn’t all get ZGC at the same time.

There's no way jetbtains isn't doing a ton of dynamic class loading

I'm assuming that's how all the plugins work?

And all the java classes for debugging, profiling, breakpoints, watch vars, etc.

It would probably make things slower. You trade faster startup for less runtime optimization.

JDK17 also supports wayland natively, one of the major blockers of having a good experience on wayland is waiting for the upgrade to JDK17.

https://youtrack.jetbrains.com/issue/JBR-1315

You sure about that? The existence of this project suggests otherwise: https://wiki.openjdk.java.net/display/wakefield/OpenJDK+Proj...

AFAIK it’s all still running on XWayland.

JDK 17 does not support Wayland natively. [Project Wakefield](https://wiki.openjdk.java.net/display/wakefield/OpenJDK+Proj...) aims to resolve that. So far, Java GUI applications only support connecting to an XWayland server when on Wayland. This is also stated in the bug you linked.

That’s extremely unfortunate and I’m not sure how I got that impression.

I’m quite certain I read this because I spent significant amounts of time trying to get IntelliJ to run on EA versions of JDK… but evidently I’m wrong as it even mentions as such in the link I pasted.

The sad thing is, there are no big technical hurdles to get like 95% of the things to run. What's unclear is how to take screenshots, how to control the mouse pointer and the mouse buttons and how to do input. These are quite far-reaching features that Wayland by design restricts for most applications.

I wouldn't want an IDE to ever warp my fucking mouse pointer!

See also this[1] ussue to track the progress. There are problems even with XWayland, e.g. on HiDPI setups. There's a work-in-progress solution [2]. If you are willing to patch the software and build from sources it will help.

[1] https://youtrack.jetbrains.com/issue/JBR-3206

[2] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

Fwiw, I tried this w/ RubyMine 2021.3.1 RC and the menu bar items stopped working. None of them display anything now, which is quite annoying, but nor really a dealbreaker because you can Cmd + Shift + A to do anything.

It amazes me that people put up with the gigabytes of RAM and full cores it takes to use Jetbrains products when VSCode/Vim/emacs can do 99% of what Jetbrains IDEs can do with LSP at a fraction of the power consumed. I guess fleet is Jetbrains acknowledging this shortcoming, but paying for current products that are marginally better than free and open source seems crazy to me.

jetbrains works for me in a way those others do not. vim and emacs are non starters. vscode is plugin hell. jetbrains just works out of the box.

Sometimes good enough defaults are really good enough.

There definitely was a time in my career (admittedly before VSCode and some of the other cool new kids on the editor block even existed) where I obsessed over vim plugins and macros and themes - but these days I love that consistent out of the box experience, too. Plus the IDEA has DataGrip embedded, and I love having a good database client right alongside the code I'm looking at.

As I've gotten older my whole philosophy with tech has shifted towards not letting the perfect be the enemy of the good, editors/IDEs included.

VSCode has also the problem that sometimes plugins work, and sometimes they just don't. Live Share for example logs me out at random times, cannot connect, or cannot find files on the remote computer. The same kind of inconsistencies appear in the Angular plugin which sometimes finds definitions, sometimes it doesn't; it's basically roulette if I can use the jump to definition or find references functions today.

With JetBrains' products I get everything out of one hand and it just works. The IDE gets out of my way and I can focus on developing. If something doesn't work I can create an issue and it will be taken seriously.

They really aren't comparable; IDEA is far ahead in profiling, refactoring, inspections, Git history integration, and probably a bunch of other things too that I haven't yet bothered to learn about.

The difference, at least with Vim and Emacs is the time it takes or time one can spend getting it all setup to do all the nice things the Jetbrains products just do out of the box.

I think the last time I fully revamped my Neovim setup I spent upwards of 40 hours learning, tweaking, and plugin shopping. And that was before Neovim shipped with it's own LSP so it was CoC. Now I'd probably spend however many hours converting my config over to the new setup.

The Jetbrains stuff just worked. I tweaked a small handful of settings and was good to go.

I'm generally allergic to anything Java, and desktop apps written in Java tend to scare me off. But I'm glad I got over that bias, because I've been pretty happy with CLion.

CoC?

https://github.com/neoclide/coc.nvim

> VSCode/Vim/emacs can do 99% of what Jetbrains IDEs can do with LSP at a fraction of the power consumed

I've never experienced a comparable editing, inspections and refactoring experience with these LSP-based editors to what I get from JetBrains' tooling. It's absolutely not 99% :)

The debugging and profiling features are excellent, too. Love the thread visualizer on PyCharm.

I’ve tried VSCode, Sublime, Vim, Eclipse, and IntelliJ for both Java and Python development. I’m more productive with IntelliJ for both (though Python is only more productive if I’m also extensively using type hints). Eclipse was the second best, but it had enough rough spots and slowness than IntelliJ still handily beat it out. The marginal productivity gain is probably in the tens of hours throughout a year, which makes it more than worthwhile for my company to pay the $99 for it.

I use Sublime for other coding where it’s fewer files (and Vim for quick text editing in consoles) and I’m quite happy with it as long as I don’t have to do any refactoring. VSCode is too slow for me in comparison and I kept running into bugs with extensions when I tried it a year ago or so.

There are a few languages I won't touch without an IDE: Java and C#. For Java I use IntelliJ and I don't write C# at all anymore. Otherwise, I use Vim. VSCode is a complete non-starter for me. I glanced at it a long while back and quickly concluded it wasn't going to give me an editor experience I would enjoy. In particular around "windows" to view files/sections of a file. Something that IntelliJ also doesn't do a good job of, but it does provide a huge advantage for Java code.

I think dynamic languages like Python also benefit from IDEs since they can do continuous static analysis to help catch errors.

Java is better with an IDE because it’s so damn verbose, and common frameworks like Spring entail a lot of “magic”.

you can write concise Java, and don't need to use Spring or similar. even then (and arguably especially then), Java IDEs (intellij, netbeans, eclipse) are a huge win since they natively speak the strong static typing and AST, allowing you to refactor much more aggressively than you otherwise could

netbeans is my personal favorite - you can throw (at least, on low end hardware) 50ish large interconnected codebases at it (microservices, libraries, frameworks, etc) and it can find usages / change signatures / rename across all of them with almost perfect results (reflection, serialization and unsafe usages are the only places i've seen them miss). intellij isn't quite as seamless for that many projects, but the code understanding is similar

Just fyi, Rider is quite good and very familiar to the IntelliJ dev if you ever have the need.

Writing code and what comes with it is the one potentially resource intensive thing I do at work. It's not like I'd be gaming at the same time. I don't really care if my programming environment takes up a few gigabytes of my 16 or 32 gigs of available memory. That's why I have it, no? Perhaps that "1%" difference is something that makes my daily work a lot nicer?

I‘d argue that one should not compare editors to IDEs as they are not comparable. I was using VIM professionally (i.e. at work) for many years until CLion showed up. Sure enough I could get around in VIM using many LLVM tools such as clang-rename, clang-format, clang-analyzer etc. but an IDE is doing much more (of rather is capable of) than editing text efficiently.

You’ve already had a lot of comments to the same effect…

But I certainly don’t mind my developer tools taking more power since that’s what I’m using my computer for. When it comes to things like Slack/Teams, where that is not the primary function of my workstation (and, by it’s nature needs to be running on everyones computer) I get more annoyed at wasted resources.

Those are secondary functions of my computer.

Web browsing, instant messaging, email. These things should be as lean as possible to get out of the way of my real work, wether that’s after effects or photoshop or visual studio (the fat one).

> But I certainly don’t mind my developer tools taking more power since that’s what I’m using my computer for

If you are okay with being chained to a power outlet, sure. I often find myself needing to be on battery power, and applications gulping electricity is frustrating at best.

(I don't use the visual design tools you listed regularly, just writing / editing code and poking API endpoints, so maybe that has much to do as well).

Guess you don’t compile while on battery either then?

Not trying to be flippant; but our jobs necessitate a lot of power consumption.

Not from scratch if I can help it. Incremental compilation is fantastic.

As with complexity, there is necessary and accidental (or lazy) power consumption. I stick to tools that are lighter on power when I am able to.

Running unit / integration tests is probably my biggest drain right now, and unfortunately (to collect coverage and ensure no unintended consequences) I end up running the entire suite probably more than is ideal.

And how is running an electron instance better than running the JVM? Also, intellij does actually have a battery saver mode which provides less intelligent autocomplete.

And just for your information, the JVM is the most power efficient managed language out there. With a somewhat saner heap size than the default the GC is very seldom run.

VSCode isn't the only alternative to Intellij. Sublime and VIM and emacs are also options, though I suspect emacs is probably a power hog- I haven't really invested a lot of time in learning to use it, though.

None of them are IDEs. Of course putting out a terminal text buffer doesn’t take much resources.

And yeah I know there are countless plugins for vim, emacs, etc. but when you are at even half of what intellij can do, it will be instable and full of bugs. Also, resource consumption does go up considerably even then.

> If you are okay with being chained to a power outlet, sure.

Maybe you need to get an M1 ;)

I can easily go a full day off power developing in Intellij.

Some language servers (e.g. PyRight) also regularly consume 2GB RAM for me when using Emacs. Also, for some languages, their IDEs are just way ahead of the competition (e.g. Java). Even for e.g. Rust CLion works really well.

(I probably use Emacs and JetBrains products 50/50. I prefer the keybindings of Doom Emacs, but prefer the JetBrains IDEs for actual development. E.g. refactoring is a lot easier.)

I'd almost forgotten that a lot of the (n)vim language servers require Node.js. The first time I tried CoC it was over an ssh session to a small VPS I had.

I started up Neovim with the new config, and promptly had my ssh session hang. It took me a little bit to figure out that I'd maxed out the 256MB of RAM on my little VPS and hard locked it. Had to get a bigger VPS to actually run my editor.

>”gigabytes of RAM […] it takes to use JetBrains” >VSCode

Not to mention that in this context it’s not even appropriate to use Vim an VSCode in the same sentence.

Are you aware that VSCode support for Java is actually based on running Eclipse headless?

Fleet does the same thing as well.

> Fleet does the same thing as well.

Did you get in to the early access group? I'd be curious what your thoughts have been so far if so!

I am inside and it is.. not that interesting to be honest. Not bad, but it is pretty much a cleared up intellij with much less functionality and an eclipse-like left pane where you can have non-project folders as well.

Regarding the much less functionality, the run button is not really configurable by much so more complicated projects can’t really be worked on yet. But I’ve just updated the package so I’m talking about a somewhat dated version.

Only watched the videos about it, I am an Eclipse/Netbeans user for Java tooling.

"Marginally"?

It millions of man-hours of development to get VS Code even remotely near what JetBrains has been doing well for over a decade, and that's being very generous in judgement. How much money was wasted trying to get Electron to not perform super shitty?

Jetbrains software has its issues but it handles and has handled nearly every language I throw it save dotnet. And I grew up on big chunky IDEs and that is what I know and like. Vim is cool (I use it for more basic tasks) but lobbing molotovs like that only furthers pointless holy wars.

There's Rider for dotnet, is that not good enough for your use case?

Haven't used it; I generally reach for full-blown Visual Studio in that case.

It still performs super shitty - I can get azure data studio to choke on 25 rows of data if its large enough. Anyone who says "vs code is faster" is in such a weird place to me.

It amazes me that someone who clearly doesn't like IDEs thinks their opinion is worth anything in a comment thread about IDE usage.

In my case it is really simple.

If I need a Java program I install IDEA. It has support for all the java frameworks, supports all the build tools, can connect to a database and show me the data inside of it.

If I code C/C++ i install CLion and do the same, with an amazing debugger etc.

When I install VSCode I got nothing. I got a glorified text editor and that's it. I first need to install what feels like thousands of plugins, only for half of those to not work, then install fifty more because I forgot I even needed those until I did.

Or to put it more simply: I don't want a text editor, I want an IDE.

If someday someone can give me a download link for a VSCode release that has all the necessary plugins for a certain language already preinstalled and does not require me to install anymore or care about how/why this stuff works then I will give it a try.

But for now I will switch with my IDE. It might not be as FOSS as other stuff, but it is more comfortable to use, enables me to be productive and it just works. That's what matters to me

I'm the same way about jvm languages, but for ruby I use RubyMine as a text editor. The navigation is a bit more powerful than text search but could also get by with only the fast searching. The main reason for the choice is familiarity.

Oh and as mentioned in another comment the git conflict resolution is stellar.

As a Python/Typescript developer I switched to IDEA from VS Code and never looked back. Debugging, code sense, full GUIs for test coverage - everything works right out of the box without tweaks or addons. Is IDEA's RAM usage massively higher, and if you starve it of RAM, does it lag obnoxiously? Of course. But I'm lucky to have a workstation that can handle it. If you do too, it's worth trying out.

Did you even try VSCode or are you just making things up? The official docs link you to a build of VSCode with Java extensions preinstalled, exactly what you’re asking for, calling the Coding Pack for Java: https://code.visualstudio.com/docs/java/java-tutorial

The OBE is much much nicer in IDEA - it figured out what I was doing (when I didn’t even know) and worked fine out of the box with Java8.

VSCode got into some loop where it demands Java 11 for highlighting code but then explodes on a Java 8 project and I’ll be arsed if I’m going to spend time debugging what’s wrong

I do use vscode for config files and other “quick load” things - it’s beating BBEdit there.

As others have mentioned, your experience seems to be drastically different from theirs. Maybe it depends on what languages you use and what features you need?

To me, IntelliJ is to Vscode as Vscode is to a plain editor without IDE features. The amount of additional value it brings is large, the level of polish compared to vscode is extreme.

It costs money and needs more resources. The licensing costs are recouped in a day or two thanks to increased productivity. The beefy workstation I use takes maybe ten days to be worth it (and Firefox likes all that extra RAM as well). And then you get an extra 20-30% more productivity for the other 350 days of the year. Feels like a no-brainer to me.

I've used VSCode for Go and TypeScript/JavaScript for years. I recently tried switching to IDEA, and the difference is just stunning.

The Go support in VSCode relies on Gopls, which is a buggy mess. It frequently just stops working. It also lacks most refactorings (and no refactor preview). The Go debugger integration is okay, but Jetbrains' is miles better.

IDEA has tons of features that makes VSCode feels positively stone age:

* The "find/replace" across files has a result view with live editing.

* "Find implementations".

* Lightning fast search across many projects in one window.

* Symbol search, also lightning fast, across many projects.

* Extensive refactoring tools. Not just things like "extract method", but also linter-driven ones like removing an unused function argument, or fixing an identifier's spelling (updates all uses).

* Git support is tons better, including things like "Compare with..." allowing instant diffing against a branch or revision.

* Diff view is much nicer. It's also "live", like many things in IDEA; if you compare two files, the diff view updates when the files are change.

* GitHub integration where you can, for example, create, view, comment on, etc. pull requests within the IDE.

* Unlike VSCode, the experience out of the box is much more complete. I only had to install a few plugins (Prettier, my favourite colour theme, etc.).

I don't mind the extra gigs of RAM when the experience is so much better.

I don't like that it's not open source. But IDEA is a classic case of commercial software being vastly more mature than open source counterparts.

IntelliJ IDEA Community Edition is actually open source: https://github.com/JetBrains/intellij-community

VSCode is not fully open source, either.

Some of your points are very true, but you should perhaps give a second try to VsCode because most of the features you describe are now available in VsCode or available in very common and popular VsCode extensions.

You need to install these extensions but that's the way it is designed, and a small JSON file is enough to have the extensions recommended in a given project.

> most of the features you describe are now available in VsCode or available in very common and popular VsCode extensions.

The question is: which extensions are those? And do they work?

With IDEA all this is just bundled. And you reach for extra extensions for, well, extra stuff that's no core functionality. With VS Code I've found it's a glorified text editor that you have make work, maybe, and unreliably.

I didn't stop using VSCode; I still use it. I only use IDEA for Go, via GoLand.

Feel free to suggest extensions that bring VSCode up to par with IDEA. The Go extension certainly isn't one of them.

For example, are there extensions to do file comparison the way describe? Or live, editable "find"? Refactoring with preview?

> * Extensive refactoring tools. Not just things like "extract method", but also linter-driven ones like removing an unused function argument, or fixing an identifier's spelling (updates all uses).

The latter is "Rename symbol", which VSCode supports for anything it has language support for, and which works across files where the language support includes that. The former is often suggested as a quick fix with VSCodes linter support. Neither is foreign to VSCode.

> Git support is tons better, including things like "Compare with..." allowing instant diffing against a branch or revision.

This is very much available for VSCode. Yes, it takes a plugin (GitLens and GitGraph are the two I use, the latter for history/branch visualizations and conducting operations from the visualization.)

> Diff view is much nicer. It's also "live", like many things in IDEA; if you compare two files, the diff view updates when the files are change.

Again, there's a plugin for that. (The one I use is just called "Diff", but the array of different Diff plugins for different preferences available for VSCode is...enormous.)

> GitHub integration where you can, for example, create, view, comment on, etc. pull requests within the IDE.

VSCode has this. I mean, sure, like almost everything else it is via plugins (the official GitHub Repositories plugin and the official GitHub Pull Requests and Issues plugin.)

> I don't like that it's not open source. But IDEA is a classic case of commercial software being vastly more mature than open source counterparts.

From your description, it seems mostly to be a classic case of an IDE having a better OOB experience for the set of functions it is intended to support than an extensible editor before considering plugins for the latter, rather than being "vastly more mature".

You cherry-picked a few things where VSCode has some extension support, but I can assure you that the differences are huge.

> The latter is "Rename symbol",

No, I'm talking about linter warnings providing smart fixes, which overall are not provided by the Go plugin, and is a mixed bag with other languages. GoLand has tons of fixes for things like unused arguments, inconsistent receiver names, incorrect spelling, and so on. And the fixes are previewed before they are applied.

But let's look at "Rename symbol". As an example of how primitive VSCode is, consider this in Go. If the rename doesn't work — for example, because it results in a conflict with an existing name in some file — it will just abort; it's all or nothing. GoLand, meanwhile, allows you to inspect the refactor preview and tweak the places where there are problems, before you apply the whole thing.

VSCode also has no awareness of implementations. If you try to rename, in IDEA, a method implemented from an interface, it will suggest altering all implementations, including the interface it came from. IDEA even goes further and will pick up strings that look related, such as in mocks, debug strings, comments, and so on.

> [Git support]

I have used GitLens, but the experience is vastly inferior to IDEA's. With GitLens, you have to compare the entire working tree (by selecting both versions to compare), which gets shown as a (not live!) snapshot in the left sidebar. You then have to click the file to compare. In IDEA, you simply select "Compare with Branch...", "Compare with Revision..." or any of the many other comparison methods, and you get the diff for the current file.

I also vastly prefer IDEA's diff UI, which can collapse unchanged portions (like classic UNIX diff). And while VSCode aligns the files strictly by inserting gaps, IDEA will cleverly align the code with visual markers, which I find much more readable. (IDEA has a toggle for the VSCode mode, of course. It also supports unified diffing as a toggle.)

I guess the GitHub PR extension has similar functionality as IDEA's, but the UI is primitive in comparison.

Is this some definition of % with an implicit divide by 10, because VSCode can't even do 1/10th of what IDEA can do for Java or Kotlin, and in basic operations like VCS, Diffing, debugging, profiling, refactoring, find/replace, code analysis, auto-generation, etc it's lightyears better.

Maybe for dynamic languages, it might not be as powerful, I'm not a heavy user of IDEA for JS or Python (but WebCharm and PyCharm do seem very good), but I will say, the Typescript support in IDEA seems very good.

Java on VSCode is fragile and odd. Refactoring sometimes off, code completions breaking etc..

IntelliJ gives you a 20% boost if that's what you do all day ... it's priceless.

I used to use VSCode for everything, now I use a 'Good IDE' if one is available.

Basic IntelliJ is also free.

There's a reason eclipse lost the marketplace. Plugin hell.

Besides what the other commenters have said, I have 32GB RAM. If Firefox or IntelliJ don't use it, nothing else will. I'd rather have the applications I live in utilise as much memory to make the experience faster and better, than to have unused RAM be wasted. IntelliJ is far superior over VS Code, VIM, etc. IntelliJ is batteries included, whereas VS Code, VIM, and most other editors require additional configurations. Some configurations I've seen have required hours and hours of set up and integration. With IntelliJ on the other hand, it just works. I click run on the main function, and it asks me for the compiler/runtime config the first time round, and afterwards it just fully works. Even running tests is as simply as clicking run from there on.

The 1% VSCode/Vim/emacs doesn't do is exactly why I use IntelliJ and PyCharm. Refactoring, code analysis and debugger integration is lightyears ahead of the competition in my experience.

It's up to you to decide if Jetbrains' stack is right for you or not. For many simple projects, it's really not worth the hassle. Just because you don't use the extra features doesn't mean nobody else does.

You clearly don't know what IntelliJ offers. I've been paying a high price for their tools for years now, and will not stop. My colleagues are often on VSCode so i've forced myself to use it and learn it so i could help them when they struggle, especially junior people.

The difference is night and day. VSCode is a light code editor. IntelliJ is a rich IDE.

The database tool in IntelliJ is better than all other specialized DB software i've tried last year when i did a market study to try and find a good DB tool. That tool is hardly even advertised and is like 1 button out of 100 buttons in the IDE. The diff tool is another example of top of the industry software rivaling stuff like Beyond Compare.

Bottomline is you seem to not have dug into it before sharing your judgment of it with people who have

I share your lamentation about Jetbrains performance/responsiveness. It's truly awful.

I still use it, because it's by far, the best code editor in terms of introspection, refactoring, managing multi-file projects etc.

Thank you -- the best parts of JetBrains' tools are brilliant, magical almost, but they are let down -- almost completely -- by the performance problems and stalling, and given that their target market is programmers (who are an opinionated and impatient lot), one would think that they would pay attention to such performance/responsiveness matters.

It is mostly due to them using an old GC algorithm instead of the default that comes with JDK 11 (what they use). Changing to G1GC with a slightly higher heap size makes quite a difference.

I don't care much about RAM tbh and CPU usage is fine. If it were faster, that'd be great. But what I get is great extensions, language support, debugger, etc.

When I've been forced to use vscode I'm pretty shocked at how weak the experience is.

This sound a bit like "I don't understand why people use planes to travel on land, I do well with my bike or my car" Sure and I'm glad we all have the choice to choose what fit our needs.

It’s simple: We are able to discern more than one percent of difference.

Technical question: What competitive advantage do you get from the story that we are crazy or stupid? Where does the assumption come from?

Reply on news.ycombinator.com