>> As a rule, scripting languages don't surpass "real" programming languages when doing the same work and with both languages free to elect their own optimized solutions;
theoretically, they can't - can they?
In theory, if compiled, its possible, but only in as much as its possible for one "real" language to be faster/slower than another "real" language. In practice, certain real languages have performance advantages over others by virtue of language design decisions, rather than, say, library implementation details.
In practice, even scripting languages that are compiled -- and lets ignore byte-code compiled scripting languages, because those cannot beat a highly-developed "real" language -- to native machine code either have not, or cannot, implement certain kinds of deep optimization techniques -- either because they are too difficult, too costly in terms of compile-time, or are essentially impossible to achieve in a scripting solution that supports hot-loading of code or are not practical/possible to achieve across the run-time/marshalling boundary. Marshaling itself is another speedbump where the scripting language's primitive types are not the host-language's primitive types, and especially where neither language's primitive types are the machine's primitive types (think CLR or JVM primitive ints, who's guaranteed behavior under shifts bigger than the machine word is one thing (IIRC), but the equivalent machine operation differs on each of ARM, x86, and x64). Still more, I'm not aware of any scripting language that exposes things like explicit memory layout of structs to the programmer, which is essential in optimization techniques such as Data-Oriented Design, but systems programming languages do.
In all, practically speaking, no scripting language will ever surpass a systems-programming language like C or C++ or Rust -- if one did, it would mean that they had achieved a breakthrough in compiler technology (and C and C++ compilers are already state-of-the-art, so no small feat). On the other hand, there are slower, natively-compiled languages, like say Swift, which at least currently is maybe half the speed of C or C++, and its possible that a highly-developed, compiled (maybe even bytecode) scripting language could best that. On the other, other hand, I'd say that Swift ought to be (and will become) faster than it is today, and even highly-developed scripting languages are likely to hit a performance ceiling before any "real" language will.