These other languages do not have the programing affordances of Java (generics, easy memory safety). Tooling is a big factor in favor of Java - IDEs, debuggers, observability etc. Also, the quality and availability of libraries is also a debatable point (although, it depends on the application at hand),
I actually disagree with all of these points and I write Java at work.
Memory safety isn't possible in Java (unlike Rust).
Tooling: they all have debuggers and observability tooling (pprof, pprof-rs, etc..). Rust even has zed now.
Libraries: Rust has really high quality packages. On the flip side, Go has almost everything built into the stdlib. Java requires a ton of third party packages of varying quality and guarantees even for basic things like logging or working with JSON. You have to constantly be on the lookout for CVE's.
In fact, 75% of the cloud-native foundations projects are in Go. K8s and docker are Go. Go is much more web-app or microservice focused than Java is actually. Most Java apps are deployed into the cloud using Go.
Meanwhile, Zig makes using the universe of C/C++ code easy.
I highly recommend you try Zig, Rust, or Go out. They weren't created out of ignorance of Java, but because Java and C++ had areas that could be improved.
Zig or Rust neither attempt to nor have any chance of directly competing with Java or any other high level language, other than on the margins (they have a hard-enough time competing with C++, which is unfortunate, because both are better than C++ -- Rust slightly so and Zig significantly so, IMO). They are for low-level development and target a domain where both the calculus of cost and value is vastly different from the high-level application space.
It is usually just as easy to write a program in a low level language as it is in a high-level one, and this is true not only for Zig and Rust, but also for C++. Even in 1998 it was just as easy to write a program in C++ as it was in Java. But the maintenance later -- when you have a large 10-year-old codebase -- is significantly more costly, and necessarily so. In a low-level language, i.e. one where there's more direct control over memory management, how a subroutine uses memory may affect its callers. Whether the correct use in the caller is enforced by the language, as in Rust, or not always, as in Zig, changes in low-level languages require touching more code than in high-level ones, and can have a bigger impact.
The low-level domain is, and will continue to be, extremely important. But the market share gap between low-level and high-level languages/domains has only grown over the past decades, and there are no signs of the trend reversing.
Now Go is a different beast altogether, and is a high level language. But it has both pros and cons compared to Java. The tools it includes in the SDK are more user-friendly, but they, like the language, are less flexible and more limited than in the Java world. Nevertheless, the out-of-the-box experience is nicer, something we should definitely improve in Java, but you pay for that simplicity later in lost flexibility. Performance also isn't quite as good as Java's, and neither is observability.
