The only benefit of bytecode is to save compiling time. Nowadays, CPU becomes much faster than the time Java was invented, 20 years ago. So the benefit is weak now. Another promoted benefit of bytecode is compile-once-run-anywhere. However, I think this is a hoax. It is not special, for script languages code runs anywhere without compiling.
I was once working on a large project on the JVM: our Fat-JAR was really working on Linux, Mac and Windows. The exact same JAR. And it didn't matter on which system we have built that JAR. This may not be possible for every use case - but I don't think it is a hoax.
> It is not special, for script languages code runs anywhere without compiling.
IMHO scripting languages like Ruby, Python, etc. are quite hard to deploy, especially if they have dependencies. In comparison to languages like Java, Go or Rust.
In terms of throughput I agree with you. But start-up latency is already Java's weakest point, and having to compile on startup would make it worse.
> Another promoted benefit of bytecode is compile-once-run-anywhere. However, I think this is a hoax. It is not special, for script languages code runs anywhere without compiling.
True as far as it goes, but certain types of code simply aren't practical in scripting languages. You'll never see people implementing e.g. an image format decoder in a scripting language; they'll use bindings to a native-compiled (C) library instead, with all the problems distributing that entails. This is why things like docker are so popular with Python users: in theory Python is write-once-run-anywhere, but in practice most Python codebases end up depending on one or more native modules and need to have the correct version compiled. Whereas Java bytecode is adequate for things like image codecs, and in the real world you really do see large Java codebases that don't use any bindings to (non-JVM) native libraries.