"Esp. The 100-500x speed loss for interpreted languages."
First, let me remind you that you have to think logarithmically here, not in absolute terms. 1-5x is the same sized range as 100-500x, about half-an-order of magnitude. (Pedants will correctly observe it isn't actually half as half an order of magnitude is actually 3.16... but it's close enough for estimate work.)
I use 50x slower than C as my guideline for how fast conventional 1990s dynamic scripting languages running an a conventional interpreter are, based on: http://benchmarksgame.alioth.debian.org/u64q/which-programs-... You can see Erlang, Perl, Ruby, Smalltalk, Python3, Lua (not LuaJIT, Lua, huge difference), and Ruby. You can find Node.JS with all the mighty power of a JIT'd language down on the next graph all the way on the right, hanging out somewhere around 10x slower than C, which seems to be all you can practically expect from a JIT'd dynamic scripting language; excepting my comments about LuaJIT in the cousin comment, I haven't see anything that convinces me you can go any faster for that crop of languages. Of course if somebody produces a 2x-slower-than-C Python JIT, I'll just update my understanding rather than insist it can't exist. But at the moment I see no particular reason to think that's going to happen.
You can also see Go at 2-3x slower than C just a bit to the right. (This is why I say Go is pretty fast for a scripting language, but you can see it's not all that fast when compared to the conventionally compiled languages. It takes a non-trivial loss on both not doing a lot of optimization, and requiring a lot of indirect vtable lookups when you use interfaces heavily which C++ often avoids and Rust aggressively avoids whenever possible.)
100-500x speed loss is just an estimate for a brand new, unoptimized scripting language... and, actually, it's a rather generous one, it could go another order of magnitude or two quite easily, especially in the very early days. Note how while that may seem extreme, it's just another order of magnitude or so slower than the optimized dynamic scripting languages. For an unoptimized implementation, that's not necessarily a terrible estimate. As I understand it, Perl 6 is currently hanging out in the 100-500x slower than C range, though I see no fundamental reason they won't catch up to the current scripting languages at the very least once they have time to optimize. (Whether than can significantly exceed them I don't know; I don't even know that it's a goal, since the dynamic scripting languages are certainly plenty fast enough for a huge variety of tasks as-is and that will continue to be true indefinitely.) These languages aren't "stuck" there, it's just that it takes time to optimize.
And my final caveat is to point out that A: fast != good and slow != bad, it's merely one element of a rich and complicated story for every language and B: that while benchmarks always have a certain subjectivity to them, we are broadly speaking observing objective facts here than, in particular, engineers responsible for creating solutions for people really, really ought to know and not dismiss because they make you feel bad. Being "insulted" at the idea Python is meaningfully fundamentally slower than Rust or something isn't going to change anything about the performance of your system, so it behooves you as engineers to be sure that you've lined your requirements, resources and solutions all up correctly.
"These languages aren't "stuck" there, it's just that it takes time to optimize"
Another thing is that we have CPU architecture that is optimized for a one size fits all system when it comes to personal computing. If we truly wanted power from higher level, more expressive languages and programming systems, we would have architecture designed for those systems.
If you want to experiment with truly new programming languages and environments, you probably have to experiment with hardware too. Our present reality makes this difficult to change, which is really too bad.
First, let me remind you that you have to think logarithmically here, not in absolute terms. 1-5x is the same sized range as 100-500x, about half-an-order of magnitude. (Pedants will correctly observe it isn't actually half as half an order of magnitude is actually 3.16... but it's close enough for estimate work.)
I use 50x slower than C as my guideline for how fast conventional 1990s dynamic scripting languages running an a conventional interpreter are, based on: http://benchmarksgame.alioth.debian.org/u64q/which-programs-... You can see Erlang, Perl, Ruby, Smalltalk, Python3, Lua (not LuaJIT, Lua, huge difference), and Ruby. You can find Node.JS with all the mighty power of a JIT'd language down on the next graph all the way on the right, hanging out somewhere around 10x slower than C, which seems to be all you can practically expect from a JIT'd dynamic scripting language; excepting my comments about LuaJIT in the cousin comment, I haven't see anything that convinces me you can go any faster for that crop of languages. Of course if somebody produces a 2x-slower-than-C Python JIT, I'll just update my understanding rather than insist it can't exist. But at the moment I see no particular reason to think that's going to happen.
You can also see Go at 2-3x slower than C just a bit to the right. (This is why I say Go is pretty fast for a scripting language, but you can see it's not all that fast when compared to the conventionally compiled languages. It takes a non-trivial loss on both not doing a lot of optimization, and requiring a lot of indirect vtable lookups when you use interfaces heavily which C++ often avoids and Rust aggressively avoids whenever possible.)
100-500x speed loss is just an estimate for a brand new, unoptimized scripting language... and, actually, it's a rather generous one, it could go another order of magnitude or two quite easily, especially in the very early days. Note how while that may seem extreme, it's just another order of magnitude or so slower than the optimized dynamic scripting languages. For an unoptimized implementation, that's not necessarily a terrible estimate. As I understand it, Perl 6 is currently hanging out in the 100-500x slower than C range, though I see no fundamental reason they won't catch up to the current scripting languages at the very least once they have time to optimize. (Whether than can significantly exceed them I don't know; I don't even know that it's a goal, since the dynamic scripting languages are certainly plenty fast enough for a huge variety of tasks as-is and that will continue to be true indefinitely.) These languages aren't "stuck" there, it's just that it takes time to optimize.
And my final caveat is to point out that A: fast != good and slow != bad, it's merely one element of a rich and complicated story for every language and B: that while benchmarks always have a certain subjectivity to them, we are broadly speaking observing objective facts here than, in particular, engineers responsible for creating solutions for people really, really ought to know and not dismiss because they make you feel bad. Being "insulted" at the idea Python is meaningfully fundamentally slower than Rust or something isn't going to change anything about the performance of your system, so it behooves you as engineers to be sure that you've lined your requirements, resources and solutions all up correctly.