Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Projects That Are Making Fast Ruby a Reality

sitepoint.com

Post reply on HN
Print view View original

1–10 of 49 posts

Re: Projects That Are Making Fast Ruby a Reality

#4

Post by 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

Re: Projects That Are Making Fast Ruby a Reality

#5

Post by nextos »

ch4s3 wrote: post #4

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

Thanks, very interesting. I didn't know about this being able to run R inside JVM. What will happen with all existing packages that have C or C++ dependencies? Perhaps it would be doable with a bridge? Having R tightly embedded in the JVM would be amazing.

Re: Projects That Are Making Fast Ruby a Reality

#6

Post by eonwe »

nextos wrote: post #5
ch4s3 wrote: post #4

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

Thanks, very interesting. I didn't know about this being able to run R inside JVM. What will happen with all existing packages that have C or C++ dependencies? Perhaps it would be doable with a bridge? Having R tightly embedded in the JVM would be amazing.

In some cases they could perhaps do the same thing that's done with Ruby: interpret the C-extensions.

It's not as crazy as it may seem and JRuby benefits hugely from it: http://chrisseaton.com/rubytruffle/cext/

Re: Projects That Are Making Fast Ruby a Reality

#7

Post by magaudet »

ch4s3 wrote: post #4

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

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.

Re: Projects That Are Making Fast Ruby a Reality

#8

Post by 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!

Post reply on HN