As a single data point, I’ve been using Python since 2005 and have never played with PyPy any beyond a quick peek after seeing a conference talk.

On the other hand, I use gcc, clang, and MSVC++ on a regular basis. But... I think the reason I care about multiple C++ compilers is mostly because there’s no “one compiler that is ergonomic to use everywhere” and I end up writing better code because of it (eg gcc warning about something clang doesn’t care about).

For Python, I mostly just care that it Just Works everywhere (modulo compiler setup for building C modules)

Almost all Python code is written for CPython, and if you run into performance issues you tweak it until it runs on pypy.

I'm glad that pypy exists because it forces cpython to do something about performance, but for python overall it's a pretty niche tool.

I'm more annoyed by the inconsistent implementations than anything else (Mostly browsers as server side still sees node being the winner).

Not to mention the terrible tooling to make multiple deployment targets possible (webpack, polyfills and whatnot)

OpenJDK is the original version of Java with a few features stripped out, not a reimplementation.

See the History section of https://en.wikipedia.org/wiki/OpenJDK?wprov=sfla1

I don't want people even competitors to steal my intellectual property so making job of those reverse engineers harder is a feature not a bug.

Compiler identification is not fairly straightforward when you remove all metadata that gives you hints. It gets worse when you fake the metadata.

My opinion echoed by many top people in reverse engineering industry.

Modern C++ is obfuscated by default due to templates, inlined functions and of course OOP.

For example, Marcus Hutchins famously echoed Boost is a cluster fuck of sadness.

My point is not about obfuscation anyway but it does helps obfuscation to some extent. It's about reverse engineering the optimized code and recover the original non-optimized code which can have a lot of use-cases.

https://www.msreverseengineering.com had a course on this subject. Experienced ones can reverse everything but my point is that it increase the barrier.

I'm not very familiar with the details, but I can comment on the results that I see: there's a multitude of python implementations (Jython, ironpython, pypy, stackless python), but only CPython has widespread adoption and there's little overlap between the ecosystems: rarely will python code be written to run on multiple implementations. I think the largest reason for this is that the CPython ecosystem is basically built on a foundation native C code (not just in the standard library but in many of the commonly used packages), and that interface is only starting to get some standardisation, as well as being very tied to CPython implementation details which made it very difficult to implement on other platforms.

In my (limited) experience with people who tried to learn Rust with a predominantly C++ background mostly struggle with trying to shoehorn some OOP design, when the language has other idioms better auite to it.

Rust does have a lot of nice ideas borrowed (hehe) from functional programming, but it's far from being FP!

On a tangent: you're comment about learning a FP before learning Rust is great advice, but not for the reasons you initially intended perhaps. Learning FP in general is great, since it teaches you a different way of thinking from the "classical" way programmers think. So, it's great to learn FP for anyone, regardless of whether it's for Rust's sake (it will help a bit with reasoning about some Rust concepts and idioms, though), or not.