And 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.

> 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.

Also 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.

I 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.