You're both right. The issue here is that both the JVM and the kernel use algorithms that can use all your RAM to speed things up, and there's no good way to know which side should 'win' (to get the best performance).
Historically the JVM will happily use all your RAM even if it doesn't need to, because that reduces the amount of GC work required which increases CPU time available to the IDE for analysis and other tasks. It can be told there's a limits, in which case it'll spend more time GCing to stay under it.
Modern JVMs changed this old default and will wait until the app is idle then start reclaiming memory and releasing it back to the OS. I guess it depends what you mean by "mid sized" but 10GB is quite a bit. It'd be worth checking that everything is running on a recent JVM. Gradle in particular can be a hog if you run it on old JVMs.
I use Rider for .Net and WebStorm for JS. Before I left work I checked, with our small/medium sized project each of them were using a little under 2gb according to windows Task Manager. Adding in some other related processes I'd estimate the two combined might be using 5-6gb in total. So I have at least 26gb left over.
To quote Lord Farquaad: That is a sacrifice I am willing to make
Historically the JVM will happily use all your RAM even if it doesn't need to, because that reduces the amount of GC work required which increases CPU time available to the IDE for analysis and other tasks. It can be told there's a limits, in which case it'll spend more time GCing to stay under it.
Modern JVMs changed this old default and will wait until the app is idle then start reclaiming memory and releasing it back to the OS. I guess it depends what you mean by "mid sized" but 10GB is quite a bit. It'd be worth checking that everything is running on a recent JVM. Gradle in particular can be a hog if you run it on old JVMs.