• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Rob Spoor
  • Bear Bibeault
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • Frits Walraven
  • Himai Minh

WG Rubyist: What does YARV bring to Ruby 1.9, future of Ruby, more...

Ranch Hand
Posts: 235
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Apart from speed, what does the YARV implementation bring to Ruby 1.9? I've read that Rails ActiveRecord is slower (right now) and that there might be some changes to the threading model. Do you think that any of the features of Ruby 1.9 will translate directly into core features in Rails?

I feel very fortunate to have found Ruby, and have a newfound appreciation for programming due to the language. Where do you see Ruby going post 1.9? Do you see Ruby becoming mainstream-enough to get serious consideration from conservative organizations?

Finally, if you could either add one feature or enhance an existing aspect of Ruby, what would that be?

Thanks again for stopping by the 'ranch!

Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Michael --

My impression has always been that the main point of YARV is the gain in speed. It's definitely had an impact in at least some other areas -- for instance, ParseTree doesn't work in 1.9.1, which I know is a big issue for people who have been doing stuff that involves AST manipulation. (I don't follow that very closely but it sounds like there's progress toward coming up with a new approach that will work.)

Koichi is definitely still at work on the threading model. There's an interesting interview with Koichi on threading and GC.

I'm not sure I understand your question about 1.9 and Rails. Do you mean will Rails start taking advantage of 1.9-only features? If so, I think it will, though as far as I know Rails 3.0 will still run on 1.8 (but I could be wrong about that).

Good question about the future of Ruby. I have no answer, though :-) I think the adoption of Ruby will increase, though there will always be organizations that simply don't look at open-source alternatives at all. It also depends on where in the organization. I've always felt, for example, that Rails is really great for intra-organizational applications, and in many cases it's a lot easier to have wide latitude of tool choice for those than for the public-facing ones.

Ruby after 1.9... well, we haven't heard as much about 2.0 in the recent past as we used to, but I believe in part that's because 1.9 is probably fairly close to what 2.0 will be. At least, as far as I know, 2.0 will use YARV and so forth. I suspect that the 1.8.6 to 1.9.1 transition will be looked back on as by far the most major change in the history of Ruby up to that point.

If I could add a feature to Ruby, it would be to restore some behavior that enumerators had for a little while and then lost. At some point during 1.9.0 development, you could do this:

array = [1,2,3]
enum = array.enum_for(:map, &lambda {|x| x * 10 })
enum.next # 10
enum.next # 20
enum.next # 30

In other words, the enumerator carried inside itself not only the hookup with the object (array) and the method (map), but also a block. That is no longer the case. I exchanged some email with Shugo on ruby-core about it, and I gather it's a performance issue. I think it's really too bad, and frankly it makes enumerators a lot less interesting to me.

An enhancement to the language I would like to see is the removal of class variables. But I don't think I'm going to win that one :-) I'd also like to see :: removed as a method-calling operator (a dot synonym). I keep seeing things like:


and I have no idea what the appeal is of it. The dot does the job just fine.

For a long time I've wanted:

class Object
def singleton_class
class << self; self; end

so then you could do:

some_object.singleton_class.class_eval ...

but I know Matz has been reluctant to add this, partly because of all the disagreement about what singleton classes should be called, and partly because he's not convinced (as I recall) that being able to grab hold of a singleton class is that important or common. Judging by how many times people end up writing that method, though, I think it would be good to have it.

I'm very glad to hear that you're enjoying Ruby and that it's rekindling your interest in programming!
Michael Sullivan
Ranch Hand
Posts: 235
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree about the :: notation, which never has felt as comfortable as dot notation. I wonder if YARV, written in C, will mean anything (aka slowdown) in the implementation of the other interpreters (JRuby, Rubinious, IronRuby). In some ways, it's interesting that the fastest Ruby interpreters are still C based.

Rails 3 on Ruby 1.8.x... that would be a surprise, but given that so much work has already gone into R3, I guess it's unavoidable. One advantage to this (that I can see) is that Rails 3 will be ported to both 1.8 and 1.9... good news for developers and hosts.

Thanks for your comments!
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic