I'm of a different opinion there. When I call e.g. sort on a list, I write what my intent is, the what; I don't care about the how, and I'd rather have the JVM decide to do a multicore / gpu driven optmized sort than that I have to think about implementation details like that.
If I want to fine-tune my implementation and write code that works well with the underlying hardware, I'd write it in a language more appropriate for that particular goal.
Java is for business applications, where the developer expresses what the code should do; lower level languages (C, Rust, etc) give the developer more options and responsibility in the how it should do it.
Simple example, for-loops vs functional functions (map, reduce, etc); the former is the how, the latter is the what.
The Java Streams API does various functional maps and reductions and can do them in a multithreaded fashion, when asked. I don't think it makes sense to parallelize by default.
Although Java is used to write all kinds of business applications, it's also used to write the platform those applications run on, like Netty for example. If I'm writing a thread pool implementation (which is eventually going to be used by "business applications"), I want to have control over concurrency. I don't want to accidentally introduce pauses in my users web apps just because I sorted an array in my library.
One could argue that web servers shouldn't be written in Java at all but you can't really support JVM applications efficiently on a non-JVM backend. All the great instrumentation tools that are available on the JVM will have trouble inspecting your library code, memory use becomes more complicated because the GC no longer knows how much memory is truly allocated, and users can't put breakpoints in your code easily in their IDE.
Even in java, you often times care about threads / core utilization. For example in a web api, you typically don't want to use multiple cores on a single client
I agree to an extent, but you have to at least be aware of the complexity of your algorithms (time and space) and understand the trade offs. If the trade offs change depending on compiler optimisations, then you'll have some difficult debugging on your hands.
If I want to fine-tune my implementation and write code that works well with the underlying hardware, I'd write it in a language more appropriate for that particular goal.
Java is for business applications, where the developer expresses what the code should do; lower level languages (C, Rust, etc) give the developer more options and responsibility in the how it should do it.
Simple example, for-loops vs functional functions (map, reduce, etc); the former is the how, the latter is the what.