3 ms·
> Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. When Java got popular, around 1999-2001, it was not a close third be
by lelanthran 1y ago
> Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad.
When Java got popular, around 1999-2001, it was not a close third behind C (or C++).
At that time, on those machines, the gap between programs written in C and programs written in Java was about the same as the gap right now between programs written in Java and programs written in pure Python.
- pjmlp 1y agoAnd yet many of us embraced Java, it became the chosen language to teach distributed systems in many Portuguese universities around 1998, because of the pain to write portable C or C++ code across UNIX clones. A mix of K&R C, C89, C++ARM compilers catching up with WG21 work, POSIX flavours, and lovely autoconf scripts.
- lelanthran 1y ago> And yet many of us embraced Java, That was my point - performance was never one of the primary considerations for enterprises. They had more important considerations.
- pjmlp 1y agoAlso as much as I complain about the lack of JIT tooling in CPython, many people forget that usually most people don't have any issues in polyglot codebases, it isn't a zero-sum game, and various forms of FFI and language bindings exist. That is one of the things I have been doing across JVM/ART, CLR, V8 for decades now, moreso if we include Perl and Tcl into the mix, I seldom write full blown 100% C or C++ code, when I reach to them, is to write native libraries or implement language bindings.
- int_19h 1y agoI don't think that's accurate. Java at the time you're describing was already JIT-compiled (HotSpot debuted in 1999), which made it drastically faster than any plain bytecode interpreter. OTOH Python was - and remains - notoriously slow because, despite being compiled to bytecode, said bytecode is extremely high level and many opcodes in it represent potential numerous dict lookups etc.