> Ironically, "run anywhere" isn't much of a requirement for backend development.
If you’re using Java, you can develop on macOS, deploy on Windows Server, then switch to Linux on AWS Graviton and M1 Macbook. Without a singe recompilation.
With graal vm java apps compiled to native have amost 0 startup time
There are no GC pauses issues practically now and for years. Language startup is also not all that much issue.
I'd say they're at a point where they're not a problem for most use cases, but if you're trying to get p9999 latency down, you might have to start looking at them.
The default GC has ridiculously good throughput with modest latency (10ms for quite large heap sizes), but there are also alternatives like ZGC and Shenandoah that optimize for latency instead, and they promise <10 ms latency, but in practice they are around 3-4 ms. At which point, not running a real time OS, you will get bigger hiccups from the OS scheduler.
Also, for very different use cases like soft real time, there are specific JVMs with real time guarantees.
Here is a great post about it: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1
And in JDK 16, ZGC has concurrent thread-stack processing, which typically reduces GC pauses below 1 ms
It's a very popular backend language. Ironically, "run anywhere" isn't much of a requirement for backend development.
> C++ is more portable because it doesn't require the JVM to run.
For backend development, this isn't much of an issue either way. These days, the main advantages C++ has to Java is startup time and no GC pauses.
It's also not as portable as you'd think. Take a look at cross-platform C/C++ projects and you'll see a lot of special cases for particular platforms.
Java's popularity mostly boils down to it's mature, has a large ecosystem, and is adequate for a lot of things. Unless you're writing an iPhone app or system-level code, it's unlikely to be a bad choice.