
Projects That Are Making Fast Ruby a Reality - MrBra
http://www.sitepoint.com/projects-that-are-making-blazing-fast-ruby-a-reality/
======
jaredcwhite
OK folks, help me out here. I'm not trying to troll, this is a genuine
question.

In the not-so-distant-past, one of the reasons why a good number of
developers/projects announced they were moving away from Ruby and using other
languages/compilers was due to Ruby's slow performance—and not just that Ruby
was slow, but that Ruby was slow due to the actual nature of the language. In
other words, Ruby was destined to always be slow, so it didn't make sense to
invest in making Ruby faster because that's, to a certain extent, a fool's
errand.

Now we're actually seeing a number of initiatives that are claiming to take
Ruby into performance arenas that are an order of magnitude faster than
before. And not just the compiler level, but all through the stack: faster app
servers, faster libraries, faster frameworks, etc.

So that's all very exciting, and I'm super thrilled as a Ruby developer, but
here's my question: if Ruby _can_ actually be a relatively fast language, what
was going on before? Were the "Ruby will always be slow" people simply wrong?
Or are there some new breakthroughs in compiler design that make it much more
feasible for such a dynamic language as Ruby to be more performant? Inquiring
minds want to know!

~~~
shanemhansen
I think the short answer is making a dynamic language really fast is really
hard. You can do it, but historically you've needed to be Sun or Google to
pull it off. Sun made java fast. Google made javascript pretty fast.

So ruby either needed to piggy back on someone else's work (jvm or whatever)
or get some next-level-smart vm developers. Even then, people have written
about how ruby presents some serious challenges.

~~~
chinhodado
Why is Java a dynamic language? Isn't Java statically typed?

~~~
ludamad
Dynamically typed languages essentially have something like Java's Object type
as the type of everything. Using wide types like that and interfaces in Java,
you easily have dynamic traits in your code.

------
mbreedlove
Ruby+Truffle+Graal support was removed from rbenv (ruby-build, actually) on
Jan. 1st.

Apparently, "the new builds are click-through licensed" and will be based off
"Oracle's JDK rather than Open JDK."

I can't wait for Oracle to die.

commit: [https://github.com/rbenv/ruby-
build/commit/ca0e1474fcf3e2025...](https://github.com/rbenv/ruby-
build/commit/ca0e1474fcf3e20257c291fb0dbe0e11ac549624)

pull request: [https://github.com/rbenv/ruby-
build/pull/864](https://github.com/rbenv/ruby-build/pull/864)

~~~
mike_hearn
That's ridiculous. Firstly, all the Graal/Truffle/Ruby work is open source.
The fact that they prefer not to maintain lots of different builds and their
build infrastructure produces a mixed open/proprietary binary doesn't change
the fact that you can get all the work for free.

Secondly, Oracle funded all of this work! Don't you think that's a little
ungrateful? How relevant do you think faster Ruby even _is_ to Oracle's core
business? Less relevant than fast JS is to Google certainly, and yet, not only
have they been funding a large cutting-edge research effort for years ... they
gave the results away as open source too.

Sometimes I think people have lost perspective. I remember programming for
Windows in the 1990s, when you were expected to pay for even basic things like
treeview widgets or networking libraries. Now you get full blown JIT compilers
for dynamic languages for nothing and people complain :(

------
ch4s3
OMR is really cool, I spun up the docker image and my project ran on it out of
the box. That said, JRuby has been great for us, and we're really excited
about Truffle+Graal (which won't run Rails yet but seems close). Chris Seaton
is super smart and a really nice guy. Apparently Truffle+Graal should be able
to run R soon
[https://twitter.com/ChrisGSeaton/status/697515513858158592](https://twitter.com/ChrisGSeaton/status/697515513858158592)

~~~
magaudet
OMR Team member here: Glad to hear you had a good experience with our tech
preview! We really appreciated the feedback you provided, and would definitely
be willing to take more.

~~~
ch4s3
You're welcome. I love the project, and I'll be watching github closely as you
move towards open source. I'll try to run some gems I like that use c
extensions soon.

------
MrBra
some discussion:
[https://www.reddit.com/r/ruby/comments/42xxsp/flammarion_the...](https://www.reddit.com/r/ruby/comments/42xxsp/flammarion_the_nifty_ruby_gui_toolkit/)

~~~
VeejayRampay
While the Reddit discussion you linked to is interesting, I'm not sure how
relevant it is to the article.

~~~
MrBra
Oops sorry you are right, I was supposed to post that inside the Flammarion
post that I made just before this one at
[https://news.ycombinator.com/item?id=11064890](https://news.ycombinator.com/item?id=11064890),
got a bit confused :)

------
singularity2001
wow, 11 sec to run hello world: ``` ~$ time ruby -X+T -e 'puts Truffle.graal?'

real 0m3.843s user 0m11.867s ```

~~~
ch4s3
That is the JVM startup time. If you allow the vm to warm up and and JIT to
kick in, you'll see significant gains.

~~~
omaranto
The JVM startup time is very small nowadays (seriously, write a Hello World!
class in Java to test it if you don't believe me). The culprit is probably
JRuby's startup time (and maybe the Truffle + Graal version of JRuby is even
slower to startup than regular JRuby).

~~~
ch4s3
Yeah, I'm oversimplifying. However, compared to MRI, the JVM starts up quite
slowly. Pile on JRuby et al and you end up with an even slower time to go. I
think the JRuby people have been very focused on feature parity, interop, and
bug fixes so I'm not sure they've prioritized startup time. For now, I'm happy
with that, I don't restart my app that often, basically only on deploys.

