I also advocate for Java, but mostly because I invested in companies that manufacture RAM.
Like Eclipse only plugins whose functionality I would have to take time I can't justify to duplicate. Plus the additional maintenance cost of the dev team no longer having a homogeneous environment. All to allow me to be able to... do what I already do.
Don't get me wrong, I'd really enjoy taking a week to explore the options and put together a better development environment for myself and my team. I do make improvements where I can already. But we're already an effective team despite Eclipse's flaws, the RoI just isn't there from a business perspective.
But seriously, I'm a huge JVM fan yet I know that if memory is a limiting factor, I should look elsewhere. I just don't current work in any environments where my program has less than 64mb to use.
While the trolling you responded to about Java and RAM is untrue, this also is not really true (I assume you meant exorbitant, not absorbent). Concurrency happens just fine in MRI in many cases because the blocker is the global interpreter lock; if you're doing I/O, threads operate concurrently in MRI. In addition, the overhead of a process in Ruby isn't all that much, and in the rare case where it is (typically a web application) you've got tools such as Unicorn that will prefork and allow you to share/COW that overhead.
The overhead for a unix process is significantly more than a lightweight JVM thread. In some cases this memory overhead can prevent you from utilizing the smaller cloud instance types which are sometimes the most cost efficient.
Also with MRI you can't light up all 4 cores, or 8 or 16 without spawning extra processes which burn memory and that can make your server less cost efficient if your app can use the RAM.
I also suggest you look into preforking and copy-on-write and ensure that you are clear on how Linux works with regards to memory usage; modern Linux systems indeed do not necessitate "burning RAM" to use multiple processes (indeed, the fork paradigm is the standard Unix approach for a reason, it only makes sense to make it performance-friendly). I would also note that while a Ruby or a Python can do this, Java, in standard configurations, cannot, were one to desire the ability to do so (and I've had reasons to run JVM applications in a multiprocess mode before).
I don't dislike Java, don't get me wrong. I write a great deal of Kotlin. But accuracy is important.
The memory overhead of a MRI ruby process running on linux is much higher than the overhead of a native JRuby thread, they are apples and oranges, surely we agree on that point because you can check it via a simple ps aux command.
Perhaps I am mistaken, but from what I've read to run unicorn following their recommended guidelines you need to spawn at least 1 MRI process for every CPU core, but if your application blocks on IO rather than CPU during it's request cycle which is common then you will need more processes than CPU cores in order to handle concurrent HTTP requests. At that point you're wasting many orders of magnitude more memory than JRuby for every "unit of concurrency" so to speak.
by the way Kotlin looks interesting, thanks for pointing it out I was not familiar
The difference in memory usage between a forked process on a shared-page/copy-on-write OS and a thread is infinitesmal. You'd have better luck arguing about having a JIT and better perf (and there you'd be incontrovertibly correct, but I don't think it really matters for 95% of everything).