> Anyway, this is really a matter of implementation, not a language issue.
I think separating the two is a bit artificial. Python being slow is partially an implementation issue but the fast implementations can't run everything. When you compare languages, you have to compare implementations, otherwise it's meaningless.
You have to compare ecosystems, but when doing so, you still have to compare PL design and PL implementation separately, because they have different implications. A quality-of-implementation issue means that something can be done, but isn't done by this particular implementation. A language limitation applies to all implementations.
That's not really true, you can go around language limitations. Go has codegen for generics, JavaScript has TS for static types, Babel for """macros""". Lots of propositions that are not in JS now can be used with Babel. Python has C extensions.
TypeScript is a different language from JavaScript, and C is a different language from Python, so I don't think those are good examples. Similarly, various macro languages that sit on top of something else are also languages in their own right.
And sure, you can always "fix" a language by designing a derivative higher-level language that transpiles into the old one. In fact, this is a time-honored tradition - C++ was originally just such a transpiler (to C). But the very fact that you have to do this points at the original design deficiencies.
I think separating the two is a bit artificial. Python being slow is partially an implementation issue but the fast implementations can't run everything. When you compare languages, you have to compare implementations, otherwise it's meaningless.