The speed argument never convinced me in general, in that whether it is perl, ruby or python, they are all slower than C. So the comparisons really are odd to me.
The "scripting" languages should of course not try to be slow, but people rarely use them for speed-reasons; they use these languages for gains in productivity and ease of writing code, adding features and so forth. That should be the primary focus point.
In the future we may no longer have such a speed penalty anyway.
slow is relative and frequently irrelevant. If you're just always waiting for network, or for results from postgres or redis or something, then a 100x speedup in your code won't change the user experience. And if you're doing computationally hard work in ruby or especially python, you're doing it wrong because either someone already wrote a native library to do it or you should.
I would “up” this a little and say that scripting languages “should” be slow in comparison to low level compiled languages. We want eg. runtime evaluation of multis dependent on type. For (cod) example:
subset Even of Int where * %% 2;
subset Odd of Int where * !%% 2;
multi foo(Even $i) { ‘fizz’ }
multi foo(Odd $i) { ‘buzz’ }
say foo for ^9;There's also "slow compared to C" and "slow enough that you notice when using it as an interactive shell". Running something like `Dir.each_child('.') {|x| p x}` in the interpreter completes in 1.3 milliseconds, which includes all the separate print calls. It could be much faster if we compute the string to print first and then only issue a single print call, but this is deliberately inefficient to show it doesn't matter in this usecase.
I wouldn't use Ruby for high performance computing. But for scripting (where runtime is not critical), web services (where transport latency will usually far outstrip the few milliseconds your handler takes) or shell use (where humans aren't fast enough to issue a new command every millisecond anyway), Ruby is more than fast enough.