>It's not, but this is a thing people have said since the early days of Java which is still going around the internet. I personally use Java every day and have yet to hear someone complain about the speed of our backends.

That's because for backends it doesn't matter. The DB layer or network will hide any slowdown anyway.

But for Desktop apps the latency due to GUI overhead and GC pauses can be from mildly annoying to unbearable.

Memory usage is still terrible with Java but at least there are plans to address part of it with value types etc. But for a web service performance is pretty good (just look at techempower benchmarks and the fact that most high scale companies use Java for a significant part of their infrastructure). If you need to talk about startup time you don't need scalablitiy or really want a different solution/architecture.

Isn't the memory use itself a big problem on modern architectures? Or has it gotten better lately since CPU clocks have been relatively flat and memory clocks have been creeping up? The problem with the "allocate-and-discard" model of programming in the past is that it thrashes the hell out of the cache, which means lots of trips to main memory, which is slow on modern machines.

When you get an article like this going "holy shit, where have you been all my life circular buffers" it emphasizes the point. You wanna go fast you have to avoid invalidating cache as much as possible.

It doesn't sound like you understand how memory Management in Java works. In Java, you have a defined heap size. Java will claim memory in order to support that heap. If you are unhappy about how much memory it is using, you can change the heap size.