But it's also the reason for why these Apache projects systematically get displaced by better and faster C, C++, Rust or Go alternatives.

Because once you have a base codebase in a particular language, it is silly to rewrite it in another, as ultimately language choice doesn't matter that much. But if you are going to rewrite stuff from scratch, Java is a horrible choice in the modern age.

When talking about Java, the question that anyone should ask is how was log4shell even allowed to happen? Like in what world would giving permission to a logging library to a) fetch code from the internet and b) execute it, by default a good decision? This wasn't a bug, it was an intentional design that passed code reviews.

Java hasn't focused on developing the standard libraries to keep up with the modern world. There is no standard http server or API libraries. A lot of the "standard" libraries in software projects are from 3d party sources like Apache, which obviously can't be trusted if they make decisions like above.

Lombok is still heavily used, and its almost a sin to write getters and setters manually instead of using it, but it works by hacking the AST, and the language maintainers never thought to include that as part of the language features.

Furthermore, the biggest use of java in android app development has shifted to use Kotlin instead, because Kotlin aims to address a lot of the pain points of Java. Yet language maintainers of Java don't seem to care.

So overall, if you look at the java ecosystem, its clear that the people working in it have no connection to use in the real world, and are taking the language into some direction that fits their convoluted ideas of what a language should be.

From a more functional perspective, in the modern age of the cloud, ARM chips, and cheap memory, developer cost outweighs infrastructure cost by orders of magnitude. If you write your service in python for MVP, you end up saving a shitload of time, through things like massive amounts of 3d party libraries, not having to wait for compile step, being able to develop during debugging session, much more flexibility in how you write code, and so on. Then as you move from MVP to a product, its much easier to refactor the code with MyPy type checking, convert collections of functions into Classes if need be, and so on. Finally, with PyPy running your code much faster than than CPython, you still will on the average be slower than Java, but not by much, and the added infra cost will be much less than a single developer salary per month.

More than that. It is a nightmare to make binding for. So if you want to really be extensible through plugins, supporting other languages is very important.

Good choice, leaves space to rewrite in rust later, right?

Step 3, Rewrite it in Rust.

Step 4, Rewrite it in Zig.

Step 5, due to security issues rewrite it in Java 63.