Correct, they're not exactly the same language, but C can be made to be compatible with C++ compilers (and is sometimes considered a subset of C++, though not exactly true). However, one wouldn't want to assume all bugs, quirks and syntax are 1:1. That would be like saying because you can drive an automatic transmission, you can easily drive a manual without any practice and knowledge beforehand.

Much more info about the compatibility and differences for anyone interested on wikipedia[1].

[1] http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

Oh I didn't mean as a matter of compatibility, although compatibility is (mostly) achievable and they share a syntactic and structural origin.

I just think that their names, common syntax and saying things like 'C++ is a [sort of] superset of C' make people unfamiliar with them think that they are more related than they are. That's why I brought up Python and Ruby - two languages that are different in syntax and many details but in the same conceptual space, whereas C and C++ look more similar, sound like almost the same thing but are, conceptually, on different planets.

Although with most JVMs being written in C, JRuby is still running on something that was built in C.

Some of them are actually meta-circular, by being implemented in Java itself.

Oracle's Project Graal plans to replace the C++ JIT by a Java one. This is based on the work of the Maxime VM.

Sure but that's true for almost all software. It's turtles/C[++] nearly all the way down, if you pick a particular way of looking at it. Besides, a modern JVM JIT does not emit C.

Regarding your JRuby vs CRuby comparison - of course, you can as well write slow code in asm vs fast code in QBasic.

You can but I don't think that's a particularly fair, representative or insightful comment on why the difference exists.

The developers of MRI are focused on developing an interesting and useful language first and everything else second. The developers of JRuby are focused on replicating that language on the JVM. They benefit from a sophisticated JIT and GC and in later JVMs some direct help, none of which diminishes their own efforts to improve performance.

Sure you can write slow code in anything but I don't see how that's in any way related to 'your JRuby/CRuby' comparison.

By that logic, any mention of any difference between any language, runtime or its implementation can simply be dismissed by 'well, they ARE all Turing equivalent!'

Yes, same goes for CPython.

I just wanted to point out on your previous comment - it is not surprise that only choosing some particular language doesn't mean a guaranteed performance.