The software industry rapidly convergng on 3 languages: Go, Rust, and JavaScript

Go: just as fast to code in as Java with a similarly shallow learning curve. Ridiculously better for targets like AWS Lambda compared to Java, even with the advent of GraalVM.

Rust: much steeper learning curve than any listed here, but can be optimized for both CPU and RAM usage to an extent no garbage collected language can match without the outsized memory integrity issues found in other systems level languages like C or C++.

For AWS Lambda, GraalVM is three times worse by latency during cold starts and double the RAM of Go. Java proper is over five times worse by latency during cold starts and over five times the RAM usage, disqualifying it for the smallest Lambda size.

You can implement a fully functional REST server in Rust in less than 20MB of RAM while it's in use with Actix or Axum and almost no CPU time. Java can get close to this in CPU efficiency, but I'd be astounded if you can even start the service in less than 50MB, and as soon as the first few requests come in, you're in the hundreds of megabytes in no time.

These scenarios may not matter to you, but they matter to a lot of folks today and even more tomorrow.

So here we are: TS/JS on the browser, often on the server, and the primary language for infrastructure tools like the AWS CDK. Go allows for much more efficient code than JS/TS on the backend once you start hitting the limits. Rust takes you to the absolute limits of the metal without compromising safety. It's not that Java couldn't fit in this mix. It's that there's no need for Java in that list. Java can't run in the browser, isn't anywhere near the best fit for lambdas, uses more resources for the same task (higher costs) in containers/K8s, and hits a hard limit for optimization at the systems level. Again, Java's definitely not going away, but it's clearly no longer the default choice for greenfield in a growing number of orgs.