Startling new proof that Ruby sucks at scripting | Hacker News Reader

Startling new proof that Ruby sucks at scripting

txt.io

22 pointsGertm27 comments

Nice how the test is performed on a release candidate version of Rubinius instead of a MRI release such as 1.9.3 or 2.0.0. This is quite a contrived test. Test it against MRI 1.9.3 and 2.0.0 and I'll consider it more accurate.

I ran this against MRI on my MacBook Pro (ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin12.0]) and got:

real 0m0.429s user 0m0.215s sys 0m0.145s

As a comparison, for Java (java version "1.6.0_43") I got:

real 0m18.856s user 0m20.529s sys 0m3.093s

rubinius 2.0.0.rc1 (1.8.7 release yyyy-mm-dd JI) [x86_64-unknown-linux-gnu]

I’ve no idea how fast Rubinius is compared to MRI 1.9.3 or 2.0 but it’s not exactly the standard interpreter. I wonder why it was chosen?

Maybe to prove his point ?

Because I tried with ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin11.4.2] and the result is more

real 0m2.835s user 0m2.236s sys 0m0.449s

(of course the computer and the system are different but still)

This benchmark is totally stupid.

I was waiting like a kid at the candy bar, which version of Ruby the OP used and then Rubinius. WTF.

Wondering what happened to collective HN hivemind to upvote a post like this.

At least do it on all three major implementations. I'd be especially curious to see how it runs in JRuby.

  Running 'awk -f bogobench.awk' 100 times…
  …done.
  real         0.70
  user         0.33
  sys          0.32
  Running 'java bogobench' 100 times…
  …done.
  real        34.25
  user        38.15
  sys          6.71
  Running 'ruby bogobench.rb' 100 times…
  …done.
  real         1.11
  user         0.56
  sys          0.42
  Running 'rbx bogobench.rb' 100 times…
  …done.
  real        41.53
  user        38.42
  sys          2.82

  awk version 20070501
  java version "1.6.0_43"
  ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.0]
  rubinius 2.0.0.rc1 (1.9.3 3981b1d0 yyyy-mm-dd JI) [x86_64-apple-darwin12.3.0]

The submitter is using Rubinius WIP in 1.8.7 mode vs stable and tested releases.

The only thing that sucks is this lackluster submission somehow being on the front page.

Just in case this post isn't satire this post is inane. And I know I risk being seen as "that guy" with the shallow and dismissive comment.

Scripting languages should be "fast enough". That's an intentionally vague requirement. And Ruby is indisputably "fast enough" for a billion little usecases.

Of course it would be better if ruby were to start up instantly. But it's absolutely not a dealbreaker and to suggest Java is a better scripting language because it starts faster strikes me as idiotic.

The measurements in the post don't prove anything and it certainly doesn't prove that Ruby sucks at scripting. The author must know this. The author must also know that measuring the time needed for a print statement isn't a meaningful performance metric.

So that means this post is either satire or intentionally provocative idiocy. Either way I don't think it's HN material. Flagged.

It's not even about the silliness of his benchmark.

His rubinius is bugged or badly compiled. Anyone who try to reproduce his benchmark will see it.

rubinius 2.0.0.rc1 (1.8.7 release yyyy-mm-dd JI) [x86_64-unknown-linux-gnu]

So much for the science.

I know I'm feeding a troll with a title like that, but the results are very strange. On my macbook:

$ ruby -v

  rubinius 2.0.0.rc1 (1.8.7 release yyyy-mm-dd JI) [x86_64-apple-darwin12.2.0]

$ time ./runner.sh ruby bogobench.rb

  Running 'ruby bogobench.rb' 100 times…
  …done.

  real	0m0.732s
  user	0m0.289s
  sys	0m0.273s

Linode with Ubuntu:

$ ruby -v

   ruby 1.9.3p392 (2013-02-22 revision 39386) [i686-linux]

$ time ./runner.sh ruby bogobench.rb

  Running 'ruby bogobench.rb' 100 times…
  …done.

  real	0m3.701s
  user	0m2.486s
  sys	0m1.202s

You aren't doing an apples to apples comparison. For example, try the AWK case 100 times and see which is faster.

This is a useless benchmark: there's no rhyme or reason for the version choices (rubinius?), the compile time is disregarded (which, for a one-off script, actually matters) and hello world is so trivial that it won't show any difference in development time.

How about choosing a nontrivial text processing example (print the second word of each line, for example) and compare the results between either a) all of the latest versions or b) the versions you would get from a fixed Linux distro (say, Ubuntu 12.04)

Code and comments in the same font and size? Irritating (at least on my phone)

2. When you talk at the end about awk and Rexx, you say they are from the 70s.. As if that's suppose to indicate they would be slower than a modern language. That's the opposite.. Of course a language designed to run on 40 year old hardware runs fat on modern hardware vs a language designed to run on modern hardware.

Heaven knows that saving milliseconds on printing "Hello, world" is a major priority with me.

Suppose that you were to demonstrate the Perl is even slower than Ruby. Would that make a difference for me? No, not unless I found that it was a bottleneck in our operations. I would keep on with Perl for two primary reasons: having used it since Perl 4, I know it in my fingers; CPAN.

The point here is to benchmark the startup time. Given how long can be some VMs to boot it's not that stupid.

The stupid things in that benchmark is that there is obviously something wrong with his ruby. Even rubinius should be an order of magnitude faster to load.

Using Ruby 2.0.0-p0, Lua 5.1.5, and LuaJIT 2.0.0 on my machine:

Lua: ~400-420ms

LuaJIT: ~390-400ms

Ruby: ~600ms

I've rarely found scriping languages most important aspect is speed. Interesting though. Didn't think of using ruby as a scripting language.

No common scripting lauguages Perl, Python (or php) in the comparison?

Ruby: 1.11s user 0.83s system 41% cpu 4.647 total

Node.js: 2.60s user 0.82s system 94% cpu 3.611 total

node -v

v0.8.9

ruby -v

ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

Write it in C or assembler and it will even be faster. That doesn't make them better choices for a script necessarily. This is one small part of picking the right path for the task at hand.

Runtime speed is the defining metric of a scripting language, then?

post and measurements like these are kindergarden posts. which speaks volumes about the fact that usually end up on the front page. scripting is a process of putting some other process in motion (e.g. some that would do millions of calculations) and for starting such a process(es) an instruction is needed every once in a while.

Flagged as flamebait.

I don't understand why I should care about this.

Anyone did it in JS?

It's cool to see how all these little examples are run for a variety of languages -- which most devs haven't used.

A Clojure example would have been really slow because Clojure adds even more slowness to the already incredibly slow JVM startup time (big Clojure fan here btw).

But it's nothing new: we know that Java, for example, totally and utterly sucks at scripting and there's a reason why scripts commonly piped on Unx systems aren't written in Java.

You still can* do some scripting in Java (or Ruby for that matters) but you have to keep in mind that it's going to be really slow.

And, yes, startup time for scripts does matter: once again there's a reason why small utils regularly piped are typically written in languages allowing fast startup time.

Reply on news.ycombinator.com