4 ms·
In the general sense I am absolutely after a faster Ruby. I am also after a Ruby with better tooling, better error handling and all bells and whistles. I'm foll
by VeejayRampay 11y ago
In the general sense I am absolutely after a faster Ruby. I am also after a Ruby with better tooling, better error handling and all bells and whistles. I'm following your development on Ruby Truffle with a lot of excitement, but like most Ruby / Ruby on Rails developers, the only thing that I wish is that I can just switch the Ruby and have it work exactly the same, except faster/better/stronger.
From what I understand JRuby/Truffle is closing the gaps at a nice pace (your recent tweets on constant folding is even showing that you're aiming not only for feature parity but for feature parity AND MOAR and that's awesome), but with existing applications and associated gems and all the implication of having to switch my Ruby to another slightly more exotic one, the thought is currently a source of anguish (because a lot of the existing ecosystem is extremely tied and tailored to MRI for better of for worse). I'm simply waiting for the time where I can just replace a line in my Gemfile and reap the benefits.
That being said, I would like to thank you for all the efforts you're putting in this, the blog entries, the Ruby Bibliography and all its promising research on making the Ruby ecosystem better, the benchmarks and overall collaboration with the folks at JRuby and I hope we get to see lots of good things in the future from your end.
- chrisseaton 11y agoYeah we're going for being indistinguishable from MRI (unless you want to use the extra features). We even have a simple statically linked build that does not require a JVM, so that you're just running a simple binary like in MRI. That coupled with our support for MRI's C extensions is our strategy for MRI compatibility.