upvote
> little do they know Ruby is a slower language than Go

Isn't it generally expected for a feature-packed interpreted language to be slower than a minimal compiled language?

reply
Ruby is compiled, it JIT compiles the code, in theory it should be on par with go once the compiler works out all the code paths, in a long-running application, you should expect the whole codebase to be compiled eventually. More:

https://www.codemancers.com/blog/rubys-jit-journey

reply
There is a big difference between JIT compiled _dynamic_ language and ahead of time compiled static language. While modern JS engines show that difference sometimes can be narrowed down with sophisticated JIT and runtime, it is still there.
reply
Ruby's YJIT compiler does compile ahead of time, the details are in the link provided. On the first run it will, if feasible, compile blocks of frequently executed code and stow it away for when it's needed next. So only on the first run is it interpreting everything.
reply
Generally being interpreted or compiled is a property of the implementation, not the language.
reply
But who cares really? I am not using Ruby for HPC. I use it for prototyping, oneliners for ETL and to glue different moving parts in a system or network together. That's it. Its not doing the heavy lifting anyways.
reply
when ruby was trendy the 1.9 branch was still cooking so in a lot of people's mind it is veery slow
reply
Yea. Modern Ruby is "fast enough", but it's very real that when Ruby was hitting its peak it was dog slow. It's hard to shake those sorts of reputations (similar to the "can't scale" reputation that Rails got because of Twitter)
reply
what matters here though is, if it is slower than bash. and that's very unlikely.
reply
Heavy lifting Python libraries are in C and C++
reply
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.

reply
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.
reply
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;
reply
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.

reply
People think slugs are slow animals... But slugs these days are faster than snails.
reply